GetInstructionBlock shows up in some compile time-intensive profiles.
Changing it to a O(1) operation. The compile benchmark confirms the
improvement.
BUG=
Review URL: https://codereview.chromium.org/1896813003
Cr-Commit-Position: refs/heads/master@{#35711}
This patch introduces new scopes in the preparser, just like they
are introduced by the parser, in the following places:
- blocks
- try statement
- switch statement
- scoped statements, in several places
- for statement
- eager function bodies
R=rossberg@chromium.org
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1906793002
Cr-Commit-Position: refs/heads/master@{#35708}
This way the first scheduler can properly wire them to the effect chain,
as otherwise the second scheduler could schedule them such that they
would be able to read uninitialized memory (once we drop the region
protection in the first scheduler).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1908963002
Cr-Commit-Position: refs/heads/master@{#35707}
Non-vectorized KeyedLoadICs used to remember whether they had seen Names
as keys; Crankshaft uses this information to avoid emitting elements
accesses which would always deopt. This CL restores that functionality
for vector ICs.
BUG=chromium:594183
LOG=y
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1912593002
Cr-Commit-Position: refs/heads/master@{#35706}
This removes the CompilationInfo argument from one of the logging
functions where it is unused. The long-term goal is to not pass around
the CompilationInfo at all. The assumption that the CompilationInfo is
available is incompatible with serialized code, where compilation has
happened during building time of V8 itself.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1901353003
Cr-Commit-Position: refs/heads/master@{#35705}
Fix for execution tests on simulator.
Port 3518e492c0
Original commit message:
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.
BUG=
Review URL: https://codereview.chromium.org/1904033003
Cr-Commit-Position: refs/heads/master@{#35703}
The JavaScript pipeline now consists of the following steps:
1. Typed lowering.
2. Representation selection (actually SimplifiedLowering).
3. Early optimization pass (incl. JSGenericLowering).
4. Effect control linearization (not for asm.js).
5. Late optimization pass (incl. ChangeLowering).
6. Real scheduling.
We should further cleanup the passes and restrict type and
representation information usage to appropriate parts of the pipeline.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1907963002
Cr-Commit-Position: refs/heads/master@{#35702}
This operator doesn't generate any actual code, but teaches the register
allocator that a certain computed pointer value is tagged. This is
required to safely implement InnerAllocate (and we also use this for
Allocate to be sure that we don't suddenly leak a dangling pointer into
the heap somewhere).
R=epertoso@chromium.org
BUG=v8:4939
LOG=n
Review URL: https://codereview.chromium.org/1905813003
Cr-Commit-Position: refs/heads/master@{#35700}
Adds a Generate method to the stubs that can be used to embed the graph directly in the bytecode handlers.
Review URL: https://codereview.chromium.org/1902823002
Cr-Commit-Position: refs/heads/master@{#35696}
This check whether a function is being debugged is obsolete. For the
optimization path it is covered by a bailout further down. The lookup
within the optimized code map doesn't need to be covered, because that
map is guaranteed to stay empty while break slots are present.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1907923003
Cr-Commit-Position: refs/heads/master@{#35694}
Rolling v8/buildtools to e84114dbe2b65428951c876349b6a3ff1afbfccd
Rolling v8/tools/clang to 2956eca572ff0e1b181df65f71a045f061a2eb34
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1909483004
Cr-Commit-Position: refs/heads/master@{#35690}
The CL #35651 (https://codereview.chromium.org/1858323003) exposed one hiden issue in RunTruncateFloat32ToUint32 test cases and X87 failed at it.
Here is the issue in RunTruncateFloat32ToUint32:
For float input = static_cast<float>(*i), the x87 GCC would optimize the input viariable in float floating register for release build.
The problem is:
SSE float register has single precision rounding semantic While X87 register hasn't when directly use floating register value. It will cause the value of input viariable has
different precision for IA32 and X87 port. So static_cast<uint32_t>(input) will be different for IA32 and X87 port too.
This led to CHECK_EQ(static_cast<uint32_t>(input), m.Call(input)) fail although V8 turbofan JITTed code m.Call(input) has exactly same result in both X87 and IA32 port.
So we add the following sentence to do type cast to keep the single precision for RunTruncateFloat32ToUint32 by forcing the input viariable get value from memory insread of
floating register.
Such as: volatile float input = static_cast<float>(*i).
BUG=
Review URL: https://codereview.chromium.org/1905883002
Cr-Commit-Position: refs/heads/master@{#35689}
This patch provides a new implementation of popcnt and ctz in the case
where the platform does not provide these instructions. Instead of
building a TF graph which implements it we now call a C function.
Additionally I turned on additional tests in test-run-wasm-64.cc
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1857363003
Cr-Commit-Position: refs/heads/master@{#35685}
Port 3518e492c0
Original commit message:
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=bmeurer@chromium.org
BUG=v8:4923,chromium:604897
LOG=N
Review URL: https://codereview.chromium.org/1902393004
Cr-Commit-Position: refs/heads/master@{#35683}
port 3518e492c0 (r35660)
original commit message:
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.
BUG=
Review URL: https://codereview.chromium.org/1904003003
Cr-Commit-Position: refs/heads/master@{#35681}
Our previous over-conservative answer caused us to emit hole checks in
full-codegen when eagerly parsing but not when lazily parsing.
With this patch, we use the positions of the BinaryOperations making up
the parameter list (which are the positions of the commas) to determine
the appropriate "end position" for each parameter's initializer. This means
that we get accurate-enough positions for the initializers in the eager
parsing step to get the same answers for hole-check-elimination that we
will later during ParseLazy.
In the included test case, for example:
(function() { ((s = 17, y = s) => s)(); } )();
^2 ^1
The old code would generate a hole check when trying to load
|s| for assignment to |y| (because it treated the closing parentheses
pointed to by "^1" as the "initialization position" of |s|).
The new code uses the comma pointed to by "^2" as the initialization
position of |s|. Since that occurs textually before the load of |s|,
full-codegen knows it can avoid the hole check.
BUG=v8:4908
LOG=n
Review URL: https://codereview.chromium.org/1900343002
Cr-Commit-Position: refs/heads/master@{#35678}
Port 81a1530e6f
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.
R=mtrofin@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1903403002
Cr-Commit-Position: refs/heads/master@{#35677}
New incoming test262 tests check what happens on detached ("neutered")
ArrayBuffers. This patch makes the test262 infrastructure define
detaching an ArrayBuffer in terms of %ArrayBufferNeuter, passing the
--allow-natives-syntax flag, when it is needed.
BUG=v8:4193
LOG=N
R=adamk,machenbach
Review URL: https://codereview.chromium.org/1897203003
Cr-Commit-Position: refs/heads/master@{#35676}
Port 81a1530e6f
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.
R=mtrofin@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/1903343002
Cr-Commit-Position: refs/heads/master@{#35674}
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, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1901423004
Cr-Commit-Position: refs/heads/master@{#35673}
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}
