- 10 Jan, 2017 7 commits
-
-
bmeurer authored
Inline calls to Math.ceil(x) as -Math.floor(-x) via the existing fast path in Crankshaft. R=ishell@chromium.org BUG=v8:5782 Review-Url: https://codereview.chromium.org/2621903002 Cr-Commit-Position: refs/heads/master@{#42161}
-
jgruber authored
Instead of exporting/importing PromiseCreate and RejectPromise and going through them, just call the runtime function / the TF builtin on the context directly. BUG=v8:5639 Review-Url: https://codereview.chromium.org/2599003002 Cr-Commit-Position: refs/heads/master@{#42160}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/87eca92..da5025b Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/487c2d0..886ff59 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d150023..b644731 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2619903003 Cr-Commit-Position: refs/heads/master@{#42159}
-
bradnelson authored
Deferred function call validation is required to support out of order asm.js function declaration. Unfortunately, since we've started interleaving validation and asm-wasm building, we don't check names are resolved until the end. Fortunately, undefined names can be detected from their CallType. Check this at asm-typer time. BUG=676797 R=aseemgarg@chromium.org,titzer@chromium.org Review-Url: https://codereview.chromium.org/2615443003 Cr-Commit-Position: refs/heads/master@{#42158}
-
zhengxing.li authored
port 38602f1f (r42146) original commit message: This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG= Review-Url: https://codereview.chromium.org/2616403007 Cr-Commit-Position: refs/heads/master@{#42157}
-
gsathya authored
R=adamk@chromium.org Review-Url: https://codereview.chromium.org/2626493002 Cr-Commit-Position: refs/heads/master@{#42156}
-
danno authored
The original TF port didn't maintain the same semantics as the CS/runtime implementation, and in fact introduced a bug that grew capacity too slowly on 32-bit platforms. R=ishell@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2617393002 Cr-Commit-Position: refs/heads/master@{#42155}
-
- 09 Jan, 2017 33 commits
-
-
bbudge authored
- Perform lane checks using FP compare instead of reinterpret casts. 0 and -0 will be different under I32 compare. - Some arithmetic operations can generate NaN results, such as adding -Inf and +Inf. Skip these tests until we have a way to do more sophisticated FP comparisons in the SIMD tests. - Eliminate a redundant F32x4 parameter for FP SIMD vector checking. We will only have this one FP type. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2594043002 Cr-Commit-Position: refs/heads/master@{#42154}
-
bbudge authored
Adds overloads for float, int32, int16, uint16, int8 and uint8 arrays. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2619223002 Cr-Commit-Position: refs/heads/master@{#42153}
-
littledan authored
Previously, the Intl implementation tracked types two ways: - In the intl_initialized_marker_symbol - In various named properties of the intl_impl_object_symbol value As far as I can tell, these will never disagree with each other, modulo bugs in Intl itself. This patch removes the second type checking system. This reland includes a fixed type check for Intl.DateTimeFormat.prototype.formatToParts , which is the only Intl method which is not bound. All future methods will follow this pattern. The second reland ensures that a newly inserted test is only run if Intl is present. BUG=v8:5751,chromium:677055, v8:4962 CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng TBR=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2623683002 Cr-Commit-Position: refs/heads/master@{#42152}
-
rmcilroy authored
Avoid allocating local objects in the outer zone, instead create a new inner zone in ValidatePendingAssessment. BUG=v8:5796 Review-Url: https://codereview.chromium.org/2617413002 Cr-Commit-Position: refs/heads/master@{#42151}
-
machenbach authored
This makes sure the metadata is found during minimization. Also renames the test files to fit the naming pattern. BUG=chromium:673246 NOTRY=true TBR=tandrii@chromium.org,mbarbella@chromium.org Review-Url: https://codereview.chromium.org/2622653002 Cr-Commit-Position: refs/heads/master@{#42150}
-
adamk authored
I can't actually figure out how to trigger a change in behavior here, but it looks like we should be passing the same attributes both to the accessor and the descriptor. R=verwaest@chromium.org Review-Url: https://codereview.chromium.org/2616843005 Cr-Commit-Position: refs/heads/master@{#42149}
-
danno authored
BUG=v8:5798 R=epertoso@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2619263002 Cr-Commit-Position: refs/heads/master@{#42148}
-
rdevlin.cronin authored
String16 had a pseudo move constructor that took a const String16&&. The problem with this is that the point of moving objects is the ability to clobber the underlying data. If we look at this particular case, the move ctor tried to then std::move the underlying std::basic_string<>; this results in passing a const std::basic_string<>&& to the basic_string ctor. This resolves to the const std::basic_string<>& *copy* ctor. So in the end, we haven't moved anything. Fix this by taking a mutable rvalue reference that allows the moving to work as expected. BUG=None Review-Url: https://codereview.chromium.org/2616973002 Cr-Commit-Position: refs/heads/master@{#42147}
-
mvstanton authored
This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
-
bjaideep authored
GCC4.8.5 on s390 emits warning "array subscript is above array bounds" for line "code[pos + 1] = kLocalVoid;". The warning seems to be correct because code[sizeof(code)] should be out of bounds. I'm suggesting to run the loop till "sizeof(code) - 1" which GCC(4.8.5) agrees with. Although this means the last byte is missed, but it should be safe to do since the last few bytes are "0xb" (kExprEnd) and the offending statement is only run when byte=kExprBlock. R=titzer@chromium.org, mstarzinger@chromium.org, bradnelson@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2619063002 Cr-Commit-Position: refs/heads/master@{#42145}
-
rmcilroy authored
Review-Url: https://codereview.chromium.org/2622453003 Cr-Commit-Position: refs/heads/master@{#42144}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2579243003 Cr-Commit-Position: refs/heads/master@{#42143}
-
clemensh authored
If you try to store an object in new space to the Code header, it will be added to the store buffer, and a DCHECK will fail later, since Code objects should never occur in the store buffer. This CL adds DCHECKs to catch such assignments early. Once we handle this case better, they can be removed again. R=mstarzinger@chromium.org, ulan@chromium.org BUG=chromium:674535 Review-Url: https://codereview.chromium.org/2587073002 Cr-Commit-Position: refs/heads/master@{#42142}
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2595733003 Cr-Commit-Position: refs/heads/master@{#42141}
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2586513002 Cr-Commit-Position: refs/heads/master@{#42139}
-
cbruni authored
The pattern IsNull(isolate) || IsUndefined(isolate) is used in many places all over the code base. Review-Url: https://codereview.chromium.org/2601503002 Cr-Commit-Position: refs/heads/master@{#42138}
-
yangguo authored
R=mvstanton@chromium.org, ulan@chromium.org BUG=v8:5808 Review-Url: https://codereview.chromium.org/2617363003 Cr-Commit-Position: refs/heads/master@{#42137}
-
franzih authored
ToName, ToObject, and ToNumber do not need an eager checkpoint. BUG= Review-Url: https://codereview.chromium.org/2623473002 Cr-Commit-Position: refs/heads/master@{#42136}
-
jkummerow authored
Review-Url: https://codereview.chromium.org/2614773004 Cr-Commit-Position: refs/heads/master@{#42135}
-
jkummerow authored
Review-Url: https://codereview.chromium.org/2614973003 Cr-Commit-Position: refs/heads/master@{#42134}
-
machenbach authored
BUG=v8:5807 NOTRY=true TBR=clemensh@chromium.org,ahaas@chromium.org Review-Url: https://codereview.chromium.org/2620653002 Cr-Commit-Position: refs/heads/master@{#42133}
-
yangguo authored
Background to this is that blink needs to be able to pass different internal fields deserialization callbacks for individual to-be-deserialized contexts. R=jochen@chromium.org, peria@chromium.org BUG=chromium:617892 Review-Url: https://codereview.chromium.org/2619203002 Cr-Commit-Position: refs/heads/master@{#42132}
-
franzih authored
BUG= Review-Url: https://codereview.chromium.org/2596803002 Cr-Commit-Position: refs/heads/master@{#42131}
-
clemensh authored
We did not associate any position to the stack check in the wasm function prologue, hence a check failed later when trying to map the non-existent position to the asm.js source position. With this CL, we add a mapping to the source position table, mapping the stack check call to byte offset 0 (which is distinct from any valid instruction position). Also, we add another entry to the asm.js source position sidetable, mapping byte offset 0 to the start source position of the function body. R=titzer@chromium.org, ahaas@chromium.org BUG=chromium:677685 Review-Url: https://codereview.chromium.org/2609363004 Cr-Commit-Position: refs/heads/master@{#42130}
-
marja authored
This adds tracking the following: - Declarations created by catch (potentially destructuring) - Declarations created by for-each (potentially destructuring) - Class declarations BUG=v8:5501, v8:5516 Review-Url: https://codereview.chromium.org/2617923003 Cr-Commit-Position: refs/heads/master@{#42129}
-
jgruber authored
The two remaining uses of this intrinsic in debug.js and mirrors.js now simply rely on the runtime function. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2591923003 Cr-Original-Commit-Position: refs/heads/master@{#41892} Committed: https://chromium.googlesource.com/v8/v8/+/c9cb94a06fa7a863d24dd6760b66cecd55748abf Review-Url: https://codereview.chromium.org/2591923003 Cr-Commit-Position: refs/heads/master@{#42128}
-
jgruber authored
BUG=v8:5805 Review-Url: https://codereview.chromium.org/2619753002 Cr-Commit-Position: refs/heads/master@{#42127}
-
zhengxing.li authored
X87: Revert of [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms (patchset #3 id:40001 of https://codereview.chromium.org/2605863002/ ). port c16ca32e (r42092) original commit message: Reason for revert: Breaks wasm benchmark (http://crbug.com/v8/5798). Original issue's description: > [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms > > Recognize and emit in-memory comparisons of 8-bit and 16-bit values with > immediate values that fit. > > LOG=N > R=epertoso@chromium.org > > Review-Url: https://codereview.chromium.org/2605863002 > Cr-Commit-Position: refs/heads/master@{#41971} > Committed: https://chromium.googlesource.com/v8/v8/+/be11812c53ff6c8ce320887bc76a3b60d8103695 BUG= Review-Url: https://codereview.chromium.org/2622463002 Cr-Commit-Position: refs/heads/master@{#42126}
-
marja authored
1) Fix confusion between for of and for in. 2) If a for loop doesn't declare its variables, no new variables are introduced (the outer scope variables are used). 3) Add more cases for destructuring for and destructuring catch. BUG=v8:5501, v8:5516 Review-Url: https://codereview.chromium.org/2614023004 Cr-Commit-Position: refs/heads/master@{#42125}
-
jochen authored
If this is possible at all, we need to at least do the first step (prepare to parse). BUG=v8:5215 R=vogelheim@chromium.org,marja@chromium.org Review-Url: https://codereview.chromium.org/2610173004 Cr-Commit-Position: refs/heads/master@{#42124}
-
bmeurer authored
Don't assume that the prototype of an object is always a JSObject when inlining the known receiver map case for abstract relational comparison. BUG=chromium:679202 R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2621583002 Cr-Commit-Position: refs/heads/master@{#42123}
-
bmeurer authored
If one input to JSStrictEqual/JSNotStrictEqual is Unique (except InternalizedString) or the hole, then we can turn that into a direct pointer comparison, as such values are only equal to exactly the same unique value. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2611363002 Cr-Commit-Position: refs/heads/master@{#42122}
-