This causes an incoming test262 test to pass, as part of the next
test262 roll.
R=adamk,machenbach
BUG=v8:1569
LOG=N
Review URL: https://codereview.chromium.org/1896293003
Cr-Commit-Position: refs/heads/master@{#35667}
Before, just a string was thrown, so no stack trace was attached there.
Generated code from wasm does not grow by this change, we just pass a
message id to the respective (new) runtime function.
R=mstarzinger@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1874383002
Cr-Commit-Position: refs/heads/master@{#35664}
clang assumes 16-byte stack alignment, but incoming stack alignment isn't
always guaranteed to be that way. It looks like v8 was lucky to not hit
this so far.
See https://crbug.com/418554 -- this makes v8's standalone config match
Chromium. See also https://llvm.org/bugs/show_bug.cgi?id=21414
Maybe it's possible to change the caller of OnEntryHook() to guarantee
the right alignment, but matching Chromium's build flags here seems like
a good idea in general.
BUG=v8:4928
LOG=n
Committed: https://crrev.com/3afb3324941625559635380ef98a2ee73e370a0a
Cr-Commit-Position: refs/heads/master@{#35597}
Review URL: https://codereview.chromium.org/1899783002
Cr-Commit-Position: refs/heads/master@{#35662}
This is just a pure renaming because "baseline" will be the code name
for our upcoming middle tier within the compilation pipeline. It makes
sure the name "baseline" remains unused.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1904463002
Cr-Commit-Position: refs/heads/master@{#35661}
Short external strings do not cache the resource data, and may be used
for compressible strings. The assumptions about their lengths is
invalid and may lead to oob reads.
R=jkummerow@chromium.org
BUG=v8:4923,chromium:604897
LOG=N
Review URL: https://codereview.chromium.org/1901573003
Cr-Commit-Position: refs/heads/master@{#35660}
Port 978ad03b92
Original commit message:
Fix and re-enable the flexible representation for Math.floor (which is used to
implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
return double results instead of int32, and therefore allows values outside
the int32 range, especially -0 is now a valid result, which doesn't deopt.
Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
extension.
This addresses all the known deoptimization loops related to Math.round
in the Kraken benchmark suite, and seems to also address most of the
deoptimization loops related to Math.floor in the Oort Online benchmark.
Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
optimization that caused the initial revert of the feature (for arm64 only
back then).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:476477,v8:2890,v8:4059
LOG=n
Review URL: https://codereview.chromium.org/1839643007
Cr-Commit-Position: refs/heads/master@{#35659}
In the long run we do not want to rely on compilation results being
available on the CompilationInfo. This removes the accessor for the
abstract code, which is very inviting to be used outside of compilation
pipeline.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1903723002
Cr-Commit-Position: refs/heads/master@{#35653}
Due to cross-compilation from simulator-builds into non-simulator with snapshot it's complicated to conditionally include an extra field. Given that the memory overhead should be minimal, just always include a separate field instead.
BUG=
Review URL: https://codereview.chromium.org/1901423002
Cr-Commit-Position: refs/heads/master@{#35652}
Also factor out test cases from test-run-machops.cc into test-run-load-store.cc
BUG=chromium:599717
LOG=Y
Review URL: https://codereview.chromium.org/1858323003
Cr-Commit-Position: refs/heads/master@{#35651}
In a full mark-compact GC, instead of copying memory to old space for
pages that have more than X% live bytes, we just move the whole page over to old
space.
X=70 (default value)
BUG=chromium:581412
LOG=N
TBR=hpayer@chromium.org
This reverts commit 8b3337278f.
Review URL: https://codereview.chromium.org/1901093002
Cr-Commit-Position: refs/heads/master@{#35649}
port 81a1530e6f (r35642)
original commit message:
Before frame elision, we finalized the frame shape when assembling the
prologue, which is also when we prepared the frame (saving sp, etc).
The frame finalization only needs to happen once, and happens to be
actually a set of idempotent operations. With frame elision, the logic for
frame finalization was happening every time we constructed the frame.
Albeit idempotent operations, the code would become hard to maintain.
This change separates frame shape finalization from frame
construction. When constructing the CodeGenerator, we finalize the
frame. Subsequent access is to a const Frame*.
Also renamed AssemblePrologue to AssembleConstructFrame, as
suggested in the frame elision CR.
Separating frame setup gave the opportunity to do away with
architecture-independent frame aligning (which is something just arm64
cares about), and also with stack pointer setup (also arm64). Both of
these happen now at frame finalization on arm64.
additional message:
This CL also removed the temporary workaround for CL #35139 (53d51c52f3)
BUG=
Review URL: https://codereview.chromium.org/1900213004
Cr-Commit-Position: refs/heads/master@{#35648}
This moves the installation of the scope info object on the shared
function info into a separate helper to share common code. This is
preparatory work in order to reuse existing scope info objects.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1894023004
Cr-Commit-Position: refs/heads/master@{#35647}
This removes some obsolete conditions checking whether we are performing
concurrent OSR compilation. This feature has been removed some time ago.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1901163003
Cr-Commit-Position: refs/heads/master@{#35646}
Previously we had to run SimplifiedLowering, ChangeLowering and
JSGenericLowering independently and exactly in this order to
achieve great performance for the common case of JSToNumber (i.e.
input is already a Smi or a HeapNumber). This phase ordering
problem already causes trouble with not being able to run the
generic lowering phase earlier, but also blocks proper plain
primitive ToNumber optimizations. So this properly integrates
JSToNumber into the truncation analysis and optimizes according
to the truncation (either Word32 or Float64).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1901803002
Cr-Commit-Position: refs/heads/master@{#35643}
Before frame elision, we finalized the frame shape when assembling the
prologue, which is also when we prepared the frame (saving sp, etc).
The frame finalization only needs to happen once, and happens to be
actually a set of idempotent operations. With frame elision, the logic for
frame finalization was happening every time we constructed the frame.
Albeit idempotent operations, the code would become hard to maintain.
This change separates frame shape finalization from frame
construction. When constructing the CodeGenerator, we finalize the
frame. Subsequent access is to a const Frame*.
Also renamed AssemblePrologue to AssembleConstructFrame, as
suggested in the frame elision CR.
Separating frame setup gave the opportunity to do away with
architecture-independent frame aligning (which is something just arm64
cares about), and also with stack pointer setup (also arm64). Both of
these happen now at frame finalization on arm64.
BUG=
Review URL: https://codereview.chromium.org/1843143002
Cr-Commit-Position: refs/heads/master@{#35642}
port 59546149c6 (r35632)
original commit message:
Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.
This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.
To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).
BUG=
Review URL: https://codereview.chromium.org/1902943003
Cr-Commit-Position: refs/heads/master@{#35641}
port 623ad7de88 (r35618)
original commit message:
Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=
Review URL: https://codereview.chromium.org/1903093002
Cr-Commit-Position: refs/heads/master@{#35640}
In JSTypedLowering we insert JSToNumber nodes for implicit type
conversions, which can potentially throw (i.e. the input not statically
known to be a plain primitive).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1900383002
Cr-Commit-Position: refs/heads/master@{#35639}
Port 59546149c6
Original commit message:
Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.
This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.
To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).
R=adamk@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1902163003
Cr-Commit-Position: refs/heads/master@{#35635}
[15.2.1.11 Static Semantics:
LexicallyDeclaredNames](https://tc39.github.io/ecma262/#sec-module-semantics-static-semantics-lexicallydeclarednames)
(in contrast with its definition for StatementListItem) makes no
explicit provision for HoistableDeclarations. This means that function
declarations are treated as lexically scoped in module code, as
described in section 15.2.1.11's informative note:
> At the top level of a function, or script, function declarations are
> treated like var declarations rather than like lexical declarations.
BUG=v8:4884
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1851673007
Cr-Commit-Position: refs/heads/master@{#35633}
Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.
This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.
To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).
Review URL: https://codereview.chromium.org/1895973002
Cr-Commit-Position: refs/heads/master@{#35632}
Prior to 89d7bfda we always just collected the code offset and computed the
source position lazily. However, for local eval we already have the source
position ready, so we can just store that. For global eval we still have to
compute from the code offset. This CL changes the computation to be done only
on demand.
R=mstarzinger@chromium.org
BUG=chromium:604646
LOG=N
Review URL: https://codereview.chromium.org/1903463002
Cr-Commit-Position: refs/heads/master@{#35630}
In addition to top source-destination pairs,
bytecode_dispatches_report.py now prints the hottest bytecode handlers
by the number of times they are executed and dispatch to another one,
regardless of the dispatch target.
Be aware that this figure does not match the number of times a handler
is executed for those which may not or will never dispatch, e.g.
Return or Throw.
BUG=v8:4899
LOG=N
Review URL: https://codereview.chromium.org/1875263004
Cr-Commit-Position: refs/heads/master@{#35629}
This prepares a patch to throw actual errors instead of just strings on
wasm traps. In order to accomplish this, the messages need to be known
to the runtime, as the generated code will just pass the message id.
R=mstarzinger@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1880493002
Cr-Commit-Position: refs/heads/master@{#35628}
Without CL debugger on StepNext adds breakpoint to function where throw instruction is located. In case of StepNext we will skip pause in this function because StepNext shouldn't break in a deeper frame.
BUG=chromium:604495
R=yangguo@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1894263002
Cr-Commit-Position: refs/heads/master@{#35627}
This is a bit unfortunate, but otherwise we would have to include
objects.h before message.h, since for the initialization of a Handle<T>,
the compiler checks that Object* can be assigned to T*. So it would
need to know about the inheritance for initializing Handle<Script> and
Handle<JSFunction>.
R=mstarzinger@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1872373002
Cr-Commit-Position: refs/heads/master@{#35626}
The guard in JSFunction::MarkForOptimization checking whether a function
is being debugged is overly protective. The compilation pipeline will
bailout itself in that circumstance. Having the runtime behave similar
makes sure the debugger observes a situation closer to reality.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1900743003
Cr-Commit-Position: refs/heads/master@{#35625}
This stops printing a log line for when a lookup in the optimized code
map did not yield a result. Logging such a negative result that will
inevitably trigger a compile anyways has little benefit and just spams
the console unnecessarily.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1904433002
Cr-Commit-Position: refs/heads/master@{#35623}
