Those two tests fail in gc-stress and custom snapshot (embedding mjsunit.js).
This is likely due to different GC timing with the custom snapshot.
R=mstarzinger@chromium.org
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1078653002
Cr-Commit-Position: refs/heads/master@{#27688}
This reduces the overhead of recursive calls when context specialization
is enabled. Based on this it might be possible to further reduce the
overhead by also specializing the call itself.
As a drive-by-fix, port the fast context materialization optimization to
arm and arm64, that was previously only supported on x64 and ia32.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1072743002
Cr-Commit-Position: refs/heads/master@{#27686}
Reason for revert:
Revert the revert as this commit cannot be the cause for the closed tree.
Original issue's description:
> Revert of X87: Reimplement Maps and Sets in JS (patchset #1 id:1 of https://codereview.chromium.org/1066373002/)
>
> Reason for revert:
> Reverting as it resulted in a closed waterfall.
>
> Original issue's description:
> > X87: Reimplement Maps and Sets in JS
> >
> > port 909500aa1d (r27605)
> >
> > original commit message:
> > Previously, the only optimized code path for Maps and Sets was for String keys.
> > This was achieved through an implementation of various complex operations
> > in Hydrogen. This approach was neither scalable nor forward-compatible.
> >
> > This patch adds the necessary intrinsics to implement Maps and Sets almost entirely
> > in JS. The added intrinsics are:
> >
> > %_FixedArrayGet
> > %_FixedArraySet
> > %_TheHole
> > %_JSCollectionGetTable
> > %_StringGetRawHashField
> >
> > With these additions, as well as a few changes to what's exposed as runtime functions,
> > most of the C++ code backing Maps and Sets is gone (including both runtime code in
> > objects.cc and Crankshaft in hydrogen.cc).
> >
> > BUG=
> >
> > Committed: https://crrev.com/56600a35a49ffa5abcba66b14839089de3589ad9
> > Cr-Commit-Position: refs/heads/master@{#27681}
>
> TBR=weiliang.lin@intel.com,chunyang.dai@intel.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/a0486f128109443ed07802fb463c267e53533d81
> Cr-Commit-Position: refs/heads/master@{#27682}
TBR=weiliang.lin@intel.com,chunyang.dai@intel.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1077543002
Cr-Commit-Position: refs/heads/master@{#27685}
port 146598f44a (r27614)
original commit message:
Optimistically pushing a lot of arguments can run into the stack limit of the
process, at least on operating systems where this limit is close to the limit
that V8 sets for itself.
BUG=
Review URL: https://codereview.chromium.org/1069283002
Cr-Commit-Position: refs/heads/master@{#27684}
Reason for revert:
Reverting as it resulted in a closed waterfall.
Original issue's description:
> X87: Reimplement Maps and Sets in JS
>
> port 909500aa1d (r27605)
>
> original commit message:
> Previously, the only optimized code path for Maps and Sets was for String keys.
> This was achieved through an implementation of various complex operations
> in Hydrogen. This approach was neither scalable nor forward-compatible.
>
> This patch adds the necessary intrinsics to implement Maps and Sets almost entirely
> in JS. The added intrinsics are:
>
> %_FixedArrayGet
> %_FixedArraySet
> %_TheHole
> %_JSCollectionGetTable
> %_StringGetRawHashField
>
> With these additions, as well as a few changes to what's exposed as runtime functions,
> most of the C++ code backing Maps and Sets is gone (including both runtime code in
> objects.cc and Crankshaft in hydrogen.cc).
>
> BUG=
>
> Committed: https://crrev.com/56600a35a49ffa5abcba66b14839089de3589ad9
> Cr-Commit-Position: refs/heads/master@{#27681}
TBR=weiliang.lin@intel.com,chunyang.dai@intel.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1073723002
Cr-Commit-Position: refs/heads/master@{#27682}
port 909500aa1d (r27605)
original commit message:
Previously, the only optimized code path for Maps and Sets was for String keys.
This was achieved through an implementation of various complex operations
in Hydrogen. This approach was neither scalable nor forward-compatible.
This patch adds the necessary intrinsics to implement Maps and Sets almost entirely
in JS. The added intrinsics are:
%_FixedArrayGet
%_FixedArraySet
%_TheHole
%_JSCollectionGetTable
%_StringGetRawHashField
With these additions, as well as a few changes to what's exposed as runtime functions,
most of the C++ code backing Maps and Sets is gone (including both runtime code in
objects.cc and Crankshaft in hydrogen.cc).
BUG=
Review URL: https://codereview.chromium.org/1066373002
Cr-Commit-Position: refs/heads/master@{#27681}
Port 9af9f1d026
Original commit message:
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
BUG=
Review URL: https://codereview.chromium.org/1073463003
Cr-Commit-Position: refs/heads/master@{#27679}
Although all this code might be moved around later, it's a good idea
to unhackify it now. :-)
Review URL: https://codereview.chromium.org/1067193004
Cr-Commit-Position: refs/heads/master@{#27672}
If we optimize a function before gathering feedback it may be
peppered with soft deoptimizations. So it can't help but deoptimize.
A judicious reading of the code isn't enough to determine what the
optimization state should be in the face of such chaotic gyrations.
BUG=
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1069363003
Cr-Commit-Position: refs/heads/master@{#27671}
This allows loopy TurboFan code to be interrupted by placing a stack
check (i.e. JSStackCheck node) into each loop. Note that we currently
limit this to non-asm.js code. Also note that stack checks are actually
placed after loop headers and not at back-branches, which allows us to
reuse existing BailoutIds from Crankshaft.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1065923002
Cr-Commit-Position: refs/heads/master@{#27666}
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1066393002
Cr-Commit-Position: refs/heads/master@{#27662}
Perhaps we should throw an exception and/or change our external API to
use a MaybeLocal, but that would be a bigger change. For now, we just
return undefined when something goes wrong with the DebugContext,
which is good enough to avoid crashing.
BUG=chromium:474538
LOG=y
Review URL: https://codereview.chromium.org/1065213002
Cr-Commit-Position: refs/heads/master@{#27650}
This is a follow-up to 2d281e71ac and prevents bailouts on empty
script contexts in Crankshaft, which don't need allocation. Only
non-empty script contexts should cause a bailout.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1063373003
Cr-Commit-Position: refs/heads/master@{#27649}
Performance measurements show that the position independent code is
usually slightly faster than the position dependent code, and there
seems to be no noticable regression.
This also gets rid of a lot of support code that was only required to allow
embedding labels into the code stream. And it implies that neither the GC
nor the deserializer need to do anything for jump tables.
R=svenpanne@chromium.org
BUG=v8:3872
LOG=n
Review URL: https://codereview.chromium.org/1069633002
Cr-Commit-Position: refs/heads/master@{#27646}
Port 2d281e71ac
Original commit message:
This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
BUG=
Review URL: https://codereview.chromium.org/1066843005
Cr-Commit-Position: refs/heads/master@{#27643}
Don't create local branches or otherwise manipulate the
checkout. This reads refs from remote branches and
reads file contents using show. It is faster and requires
less bootstrapping and cleanup.
TBR=tandrii@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/1060013003
Cr-Commit-Position: refs/heads/master@{#27640}
The ES6 grammar forbids the initialization of variable declarations in IterationStatements.
This CL will report `for (var x = y in z)` as a SyntaxError in strict mode (as done in JSC). It is possible that this could break sites in sloppy mode, and so that change can wait.
BUG=
R=
LOG=N
Review URL: https://codereview.chromium.org/1033823002
Cr-Commit-Position: refs/heads/master@{#27639}
