In the process also inline the stub into the appropriate interpreter bytecode
handler and make sure that the context register is preserved in hand-written
assembly code that calls the stub and expects the context register to be
preserved.
BUG=608675
Review-Url: https://codereview.chromium.org/2188993003
Cr-Commit-Position: refs/heads/master@{#38132}
This patch updates internal data structures used by V8 to support
multiple indirect function tables (WebAssembly/design#682). But, since
this feature is post-MVP, the functionality is not directly exposed and
parsing/generation of WebAssembly is left unchanged. Nevertheless, it
is being used in an experiment to implement fine-grained control flow
integrity based on C/C++ types.
BUG=
Review-Url: https://codereview.chromium.org/2174123002
Cr-Commit-Position: refs/heads/master@{#38110}
Objects that reside below the age mark could be on pages that have been moved
within new space. In this case mementos survived which can actually point to
already-collected allocation sites.
BUG=chromium:631050,chromium:581412
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2179033005
Cr-Commit-Position: refs/heads/master@{#38094}
This required the introduction of the CheckedNumberOrOddballAsWord32 use info, and a change in the RepresentationChanger to handle it.
BUG=
Review-Url: https://codereview.chromium.org/2184513003
Cr-Commit-Position: refs/heads/master@{#38086}
Reason for revert:
Fix has been landed.
Original issue's description:
> Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ )
>
> Reason for revert:
> Bunch of breakages. Maybe bad interaction with e520e5da55 ?
>
> E.g.:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
>
> Original issue's description:
> > [interpreter] Add explicit OSR polling bytecode.
> >
> > This adds an explicit {OsrPoll} bytecode into every loop header which
> > triggers on-stack replacement when armed. Note that each such bytecode
> > stores the static loop depths as an operand, and hence can be armed for
> > specific loop depths.
> >
> > This also adds builtin code that triggers OSR compilation and switches
> > execution over to optimized code in case compilation succeeds. In case
> > compilation fails, the bytecode dispatch just continues unhindered.
> >
> > R=rmcilroy@chromium.org
> > TEST=mjsunit/ignition/osr-from-bytecode
> > BUG=v8:4764
> >
> > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> > Cr-Commit-Position: refs/heads/master@{#38043}
>
> TBR=rmcilroy@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4764
>
> Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc
> Cr-Commit-Position: refs/heads/master@{#38044}
TBR=rmcilroy@chromium.org,machenbach@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2184713002
Cr-Commit-Position: refs/heads/master@{#38056}
Reason for revert:
Bunch of breakages. Maybe bad interaction with e520e5da55 ?
E.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
Original issue's description:
> [interpreter] Add explicit OSR polling bytecode.
>
> This adds an explicit {OsrPoll} bytecode into every loop header which
> triggers on-stack replacement when armed. Note that each such bytecode
> stores the static loop depths as an operand, and hence can be armed for
> specific loop depths.
>
> This also adds builtin code that triggers OSR compilation and switches
> execution over to optimized code in case compilation succeeds. In case
> compilation fails, the bytecode dispatch just continues unhindered.
>
> R=rmcilroy@chromium.org
> TEST=mjsunit/ignition/osr-from-bytecode
> BUG=v8:4764
>
> Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> Cr-Commit-Position: refs/heads/master@{#38043}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2184553003
Cr-Commit-Position: refs/heads/master@{#38044}
This adds an explicit {OsrPoll} bytecode into every loop header which
triggers on-stack replacement when armed. Note that each such bytecode
stores the static loop depths as an operand, and hence can be armed for
specific loop depths.
This also adds builtin code that triggers OSR compilation and switches
execution over to optimized code in case compilation succeeds. In case
compilation fails, the bytecode dispatch just continues unhindered.
R=rmcilroy@chromium.org
TEST=mjsunit/ignition/osr-from-bytecode
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2172233002
Cr-Commit-Position: refs/heads/master@{#38043}
When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.
This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.
Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.
R=yangguo@chromium.org
BUG=chromium:631318
Review-Url: https://codereview.chromium.org/2182003002
Cr-Commit-Position: refs/heads/master@{#38038}
After multiplying two integers we emit code like:
if (result == 0) {
if (OR_OPERATION(rhs, lhs) < 0) {
DEOPT;
}
}
This CL allows us to eliminate the OR and comparison if either rhs or
lhs is a negative number, reducing the code to:
if (result == 0) DEOPT;
BUG=
Review-Url: https://codereview.chromium.org/2167643002
Cr-Commit-Position: refs/heads/master@{#38016}
Introducing machine operators early causes trouble for the typing,
truncation analysis and representation selection, so we should rather
stick to simplified operators instead. Now there's only the for-in case
left, which is not clear how we can handle this in a better way.
Drive-by-fix: Also don't introduce Int32Constant and Word32Shl in
JSTypedLowering, but use NumberConstant and proper NumberShiftLeft
operators instead.
R=jarin@chromium.org
BUG=chromium:630951
Review-Url: https://codereview.chromium.org/2182453002
Cr-Commit-Position: refs/heads/master@{#38008}
The dead code elimination in SimplifiedLowering can eliminate pure nodes
if they don't have value uses. But some of those can indeed have control
inputs, i.e. Phi nodes do of course have a control input.
R=jarin@chromium.org
BUG=chromium:630923
Review-Url: https://codereview.chromium.org/2177133002
Cr-Commit-Position: refs/heads/master@{#37995}
In PrependElementIndicesImpl we sort a FixedArray of indices potentially
containing HeapNumbers. During the string conversion we might trigger a GC.
This in turn might try to read a slot where we previously had a HeapNumber
but the sort sneaked a SMI in there which is not a valid pointer.
BUG=chromium:630561
Review-Url: https://codereview.chromium.org/2173653003
Cr-Commit-Position: refs/heads/master@{#37993}
This allows us to skip complicated logic for setting the accessors.
BUG=
Review-Url: https://codereview.chromium.org/2164903004
Cr-Commit-Position: refs/heads/master@{#37969}
This is in preparation to implementing exception prediction for async
functions. Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.
To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.
The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}
See discussion in https://codereview.chromium.org/2156303002/#msg8
With the new --harmony-function-tostring behavior, these tests would
fail without this change. This change makes the tests pass regardless
of whether or not --harmony-function-tostring is used.
All of these changes are simply inserting a space after the "function"
keyword to match the current function toString behavior. When
--harmony-function-tostring is enabled, the toString behavior matches
the spacing used in the function declaration. With the declaration
matching the current formatting, the toString behavior becomes
unaffected by --harmony-function-tostring.
BUG=v8:4958
LOG=n
Review-Url: https://codereview.chromium.org/2161413002
Cr-Commit-Position: refs/heads/master@{#37959}
This cl also fixes two bugs in the previous code:
1) JITed functions were not allowed access to the heap because the module instance wasn't correctly synthesized. This wasn't discovered in the previous test.
2) Decoding of functions with the JITSingleFunction opcode was off by 1 as the length of the opcode wasn't computed correctly.
BUG=5044
Review-Url: https://codereview.chromium.org/2168183002
Cr-Commit-Position: refs/heads/master@{#37957}
Use the ForInFilterStub directly. Hence we will only jump to the runtime for
special receivers (instance_type <= LAST_SPECIAL_RECEIVER_TYPE) and for
converting element indices which are not in the string cache.
BUG=
Review-Url: https://codereview.chromium.org/2151773002
Cr-Commit-Position: refs/heads/master@{#37934}
The optimizing compilers actually invoke %TransitionElementsKind for
any kind of JSObject, the only relevant thing is the elements kind.
The runtime function was however checking for JSArray unnecessarily.
This only worked by coincindence in Crankshaft because the stub would
normally not call into the runtime fallback.
R=jarin@chromium.org
BUG=chromium:629823
Review-Url: https://codereview.chromium.org/2166963004
Cr-Commit-Position: refs/heads/master@{#37919}
This CL more or less reverts commit https://codereview.chromium.org/2107733002/
The use of the MathPow code stub that was introduced by that commit caused
problems on arm64, and the MathPow code stub was also an obstacle in the
implementation of parallel code generation.
In addition this CL turns on the mjsunit/wasm/embenchen tests for arm64
which were turned off because of problems with MathPow on arm64.
R=titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2166793002
Cr-Commit-Position: refs/heads/master@{#37911}
As required by the spec.
This is a variant of what I reverted in f47e722403.
It will probably still cause a regression but now it's easier to migrate (parts of)
the current implementation to C++, which is expected to make things faster again.
BUG=chromium:627729,v8:5113
Review-Url: https://codereview.chromium.org/2164923002
Cr-Commit-Position: refs/heads/master@{#37897}
This ports a large portion of Error methods to C++,
including the constructor, stack setter and getter,
and Error.prototype.toString.
BUG=
Review-Url: https://codereview.chromium.org/2142933003
Cr-Commit-Position: refs/heads/master@{#37870}
We need to pay attention to potential side effects from parameter
evaluation when inlining the fast case Array.prototype.shift.
R=yangguo@chromium.org
BUG=chromium:614644
Review-Url: https://codereview.chromium.org/2161943002
Cr-Commit-Position: refs/heads/master@{#37850}
Original issue's description:
> Don't compile functions in a context the caller doesn't have access to
>
> Instead just return undefined
>
> A side effect of this is that it's no longer possible to compile
> functions in a detached context.
>
> BUG=chromium:541703
> R=verwaest@chromium.org,bmeurer@chromium.org
BUG=chromium:541703
R=verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2155503004
Cr-Commit-Position: refs/heads/master@{#37842}
The bug occurs because we do not canonicalize character class ranges
before adding case equivalents. While adding case equivalents, we abort
early for one-byte subject strings, assuming that the ranges are sorted.
Which they are not.
R=marja@chromium.org
BUG=v8:5199
Review-Url: https://codereview.chromium.org/2159683002
Cr-Commit-Position: refs/heads/master@{#37833}
This makes sure that we preserve call's tailness even if we have
introduced a loop exit between the call and the return.
BUG=chromium:628773
Review-Url: https://codereview.chromium.org/2155123002
Cr-Commit-Position: refs/heads/master@{#37832}
