Hydrogen logs are ambiguous if multiple functions share the same name.
This change adds file names to this output. Functions are now named
<file_name>:<function_name> to reduce this ambiguity.
R=ofrobots@google.com
BUG=
Review-Url: https://codereview.chromium.org/1913973004
Cr-Commit-Position: refs/heads/master@{#36076}
- Cleanup CL to remove unused parameters in elements.cc. Additionally use fields
from the KeyAccumulator wherever possible.
- Make method names in KeyAccumulator more consistent
BUG=
Review-Url: https://codereview.chromium.org/1944703002
Cr-Commit-Position: refs/heads/master@{#36073}
This moves all the machinery for tracing inlined function that is
specific to Crankshaft into the appropriate component. Only the old
side-channel via a list of InlinedFunctionInfo structs remained within
the CompilationInfo for now. In the long run we will reconstruct that
information from the deoptimization data on the code objects.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/1944323002
Cr-Commit-Position: refs/heads/master@{#36068}
This changes different locations to extract the reference to the wasm
object and the function index from the stack trace, and make it
available through all the APIs which process stack traces.
The javascript CallSite object now has the new methods isWasm(),
getWasmObject() and getWasmFunctionIndex(); the byte offset is
available via getPosition().
Function names of wasm frames should be fully functional with this
commit, position information works reliably for calls, but not for
traps like unreachable or out-of-bounds accesses.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1909353002
Cr-Commit-Position: refs/heads/master@{#36067}
Reason for revert:
Breaks WASM; please also add tests when relanding.
Original issue's description:
> [turbofan] Take the immediate size in account when narrowing ia32/x64 word comparison operators.
>
> Before this patch, we would emit a cmp or test with a memory operand only if both of the operands in the IR were loads. Now if either of them is a load and the other one is an immediate, we can use a memory operand if the load representation machine size is wide enough to represent the latter.
>
> Committed: https://crrev.com/a0543313dbd46b0c2e72c91ee3488a7dc6db73e4
> Cr-Commit-Position: refs/heads/master@{#36009}
TBR=bmeurer@chromium.org,jfb@chromium.org,epertoso@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/1959603002
Cr-Commit-Position: refs/heads/master@{#36066}
This operator was initially designed to handle arbitrary effect merging
for effect relaxation, but we don't do that (at least currently). So no
need to keep the dead operator around.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1954983002
Cr-Commit-Position: refs/heads/master@{#36063}
Rolling v8/build to 119d5305247498fdd8a215b8e2b6c50223ac7d4b
Rolling v8/tools/clang to 0bb0462a91310d88ab9d124d8db54a70c9e1d1b0
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/1953813004
Cr-Commit-Position: refs/heads/master@{#36059}
port 117a56b7c2 (r36044)
original commit message:
- Add new RelocInfo mode WASM_MEMORY_SIZE_REFERENCE in the assembler and add relocation information to immediates in compare instructions.
- Use relocatable constants for MemSize/BoundsCheck in the wasm compiler
BUG=
Review-Url: https://codereview.chromium.org/1947413003
Cr-Commit-Position: refs/heads/master@{#36058}
port a0543313db (r36009)
original commit message:
Before this patch, we would emit a cmp or test with a memory operand only if both of the operands in the IR were loads.
Now if either of them is a load and the other one is an immediate, we can use a memory operand if the load representation machine size is wide enough to represent the latter.
BUG=
Review-Url: https://codereview.chromium.org/1954963002
Cr-Commit-Position: refs/heads/master@{#36057}
Rolling v8/build to f80756f5df1d90cf1113a2ce335147482e36f65e
Rolling v8/buildtools to 731bdb2af8b5839450605ddebdcf5de749cf9d17
Rolling v8/tools/clang to ee715658a19a60fc73b02532a077d9c96f291331
Rolling v8/tools/gyp to 02b145a1a4f4e1c62e8bae06045caf852d9ef17f
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/1945103004
Cr-Commit-Position: refs/heads/master@{#36050}
Scope analysis is over-conservative when treating variable resolutions
as possibly-shadowed by a sloppy eval. In the attached bug, this comes
into play since catch scopes have different behavior with respect to
the "calls eval" in eager vs lazy compilation (in the latter, they
are never marked as "calls eval" because CatchContexts don't have
an associated ScopeInfo).
This patch changes the scope-type check to also eliminate a few other
cases where shadowing isn't possible, such as non-declaration block scopes.
BUG=chromium:608279
LOG=n
Review-Url: https://codereview.chromium.org/1950803002
Cr-Commit-Position: refs/heads/master@{#36046}
A load instruction will implicitely clear the top 32 bits when writing to a W
register. This patch avoids generating a `mov` instruction to zero-extend the
result in this case.
For example, this occurs in the generated code for dispatching to the next
bytecode in the interpreter:
kind = BYTECODE_HANDLER
name = LdaZero
compiler = turbofan
Instructions (size = 36)
0x32e64c60 0 add x19, x19, #0x1 (1)
0x32e64c64 4 ldrb w0, [x20, x19]
0x32e64c68 8 mov w0, w0
^^^^^^^^^^
0x32e64c6c 12 lsl x0, x0, #3
0x32e64c70 16 ldr x1, [x21, x0]
0x32e64c74 20 movz x0, #0x0
0x32e64c78 24 br x1
BUG=
Review-Url: https://codereview.chromium.org/1950013003
Cr-Commit-Position: refs/heads/master@{#36038}
Previously, the species protector was invalidated whenever the __proto__ of
an Array instance was manipulated. Then, if the map's new_target_is_base field
remained set, it was correct to conclude that GetPrototypeOf(array) was
%ArrayPrototype%. However, this choice caused the popular D3 framework to
invalidate the species protector, causing many functions to become slower.
This patch eliminates that aspect of the species protector. Instead, the check
is to look at the instance->map()->prototype(). It is valid to look directly
at the map's prototype slot, ignoring hidden prototypes and proxies, because
- This is only called on Array instances, so the receiver cannot be a Proxy.
- For hidden prototypes, any inaccuracy would only result in conservatively
taking the slow path.
Theoretically, this patch could make methods applied to arrays from other
contexts slower. However, the slowdown would only affect a particular array
instance and not have a global spill-over effect. Further, the slowdown could
be addressed by tracking, either in the instance's map or in the actual
prototype object, whether it is a %ArrayPrototype% from any context, in a way
which is cheap to query, and use that rather than comparing to the currently
executing native context.
In interactive testing, this patch led the OnShape CAD system to experience
faster load times (110+s -> 40s).
BUG=chromium:606207
LOG=Y
Review-Url: https://codereview.chromium.org/1936393002
Cr-Commit-Position: refs/heads/master@{#36033}
This method provides ability to get all properties of the object with passed filter in addition to existing GetOwnPropertyNames(context) method that returns only enumerable properties.
BUG=v8:3861,chromium:581495
R=yangguo@chromium.org
LOG=Y
Review-Url: https://codereview.chromium.org/1943773002
Cr-Commit-Position: refs/heads/master@{#36031}
This removes some low-level accessors from the CompilationInfo which
only delegate to the ParseInfo. Instead we add a helper that computes
the flags passed to DeclareGlobals for all backends.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1952623002
Cr-Commit-Position: refs/heads/master@{#36030}
We sometimes used to continue by jumping _back_ to the condition check at the
top of the loop. After my recent generator-related changes, that check is no
longer at the loop header, so a continue could create an additional loop. In
order to avoid this, we now always set the continue target to be the first
instruction following the loop body.
BUG=
Review-Url: https://codereview.chromium.org/1943383003
Cr-Commit-Position: refs/heads/master@{#36029}
