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}
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}
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}
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}
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}
Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved.
--harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time.
This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object.
BUG=v8:4915
LOG=N
Review-Url: https://codereview.chromium.org/1928203002
Cr-Commit-Position: refs/heads/master@{#36024}
Now that everything is properly wired to the effect chain when we get to
ChangeLowering, we can safely inline the allocation fast path and only
need to consule the slow path stub fallback when bump pointer allocation
fails.
R=jarin@chromium.org
BUG=v8:4931
LOG=n
Review-Url: https://codereview.chromium.org/1951853002
Cr-Commit-Position: refs/heads/master@{#36022}
This fixes a bug where returning from a class literal inside
a try-finally didn't restore the context properly when
entering the finally clause.
BUG=v8:4965
LOG=n
Review-Url: https://codereview.chromium.org/1952633002
Cr-Commit-Position: refs/heads/master@{#36021}
It is already effectively disabled by --scavenge_reclaim_unmodified_objects.
BUG=
Review-Url: https://codereview.chromium.org/1944793002
Cr-Commit-Position: refs/heads/master@{#36018}
This allows for top-level eval code to be parsed properly before doing
optimization. It uses the same kind of re-parsing we already perform
when compiling code for debugging.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/1884143003
Cr-Commit-Position: refs/heads/master@{#36014}
When storing an immediate integer or floating point zero, use the zero register
as the source value. This avoids the need to sometimes allocate a new register.
BUG=
Review-Url: https://codereview.chromium.org/1945783002
Cr-Commit-Position: refs/heads/master@{#36013}
The inline allocation sequence in the optimizing compilers cannot deal
well with funky types like JSRegExp, which have some magic fields in
addition to the inobject properties. In Crankshaft we already use the
FastNewObjectStub for %_NewObject in general, so fix TurboFan to the same.
Hopefully one day we can kill %_NewObject completely.
R=jarin@chromium.org
BUG=chromium:609029
LOG=n
Review-Url: https://codereview.chromium.org/1943403004
Cr-Commit-Position: refs/heads/master@{#36006}
Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.
Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.
BUG=v8:4970
LOG=n
Review-Url: https://codereview.chromium.org/1931003003
Cr-Commit-Position: refs/heads/master@{#36001}
The problem is actually not related to try-catch, so here is a test
without try-catch.
BUG=chromium:607493
LOG=n
Review-Url: https://codereview.chromium.org/1943883002
Cr-Commit-Position: refs/heads/master@{#35985}
Reason for revert:
Jakob found the actual issue with the CL and is going to land the fix after relanding the WB elimination.
Original issue's description:
> Revert of [turbofan] Restore basic write barrier elimination. (patchset #2 id:20001 of https://codereview.chromium.org/1938993002/ )
>
> Reason for revert:
> Breaks WBs that should be there ;)
>
> https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/3305
>
> Will open repro bug asap.
>
> Original issue's description:
> > [turbofan] Restore basic write barrier elimination.
> >
> > Restore the basic write barrier elimination that we used to run as part
> > of the simplified lowering phase (in ChangeLowering actually) before, by
> > moving the write barrier computation to SimplifiedLowering where we can
> > still look at types and consider the heap/isolate, and just update the
> > WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
> > lowering to a machine Load/Store.
> >
> > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
> > R=mstarzinger@chromium.org
> > BUG=v8:4969,chromium:608636
> > LOG=n
> >
> > Committed: https://crrev.com/7dcb6ad379fbacbc8bdc8e11a6e50d680ffa3f62
> > Cr-Commit-Position: refs/heads/master@{#35969}
>
> TBR=mstarzinger@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4969,chromium:608636
>
> Committed: https://crrev.com/a782e93c617e728cded5ad878de11137a67891b7
> Cr-Commit-Position: refs/heads/master@{#35983}
TBR=mstarzinger@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4969,chromium:608636
Review-Url: https://codereview.chromium.org/1943323002
Cr-Commit-Position: refs/heads/master@{#35984}
Reason for revert:
Breaks WBs that should be there ;)
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/3305
Will open repro bug asap.
Original issue's description:
> [turbofan] Restore basic write barrier elimination.
>
> Restore the basic write barrier elimination that we used to run as part
> of the simplified lowering phase (in ChangeLowering actually) before, by
> moving the write barrier computation to SimplifiedLowering where we can
> still look at types and consider the heap/isolate, and just update the
> WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
> lowering to a machine Load/Store.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
> R=mstarzinger@chromium.org
> BUG=v8:4969,chromium:608636
> LOG=n
>
> Committed: https://crrev.com/7dcb6ad379fbacbc8bdc8e11a6e50d680ffa3f62
> Cr-Commit-Position: refs/heads/master@{#35969}
TBR=mstarzinger@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4969,chromium:608636
Review-Url: https://codereview.chromium.org/1943743003
Cr-Commit-Position: refs/heads/master@{#35983}
Restore the basic write barrier elimination that we used to run as part
of the simplified lowering phase (in ChangeLowering actually) before, by
moving the write barrier computation to SimplifiedLowering where we can
still look at types and consider the heap/isolate, and just update the
WriteBarrierKind in the FieldAccess/ElementAccess that we later use when
lowering to a machine Load/Store.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
R=mstarzinger@chromium.org
BUG=v8:4969,chromium:608636
LOG=n
Review-Url: https://codereview.chromium.org/1938993002
Cr-Commit-Position: refs/heads/master@{#35969}
Yield expressions are not allowed in formal parameter initializers of
generators, but we weren't properly catching the case where the yield
expression appeared in the 'extends' clause of a class expression.
They also aren't allowed in arrow functions, which we were failing to
catch due to not looking at the obscurely-named "FormalParameterInitializerError"
bit of ExpressionClassifier.
This patch passes along an ExpressionClassifier when parsing class
expressions and accumulates the proper error for that case.
For the arrow function case, the fix is simply to check for the
"formal parameter initializer" error once we know we've parsed
an arrow function. The error message used for this has also
been made specific to yield expressions.
Tests are added both for the error case and the non-error cases (where
yield is used in such a position inside the class body).
BUG=v8:4966, v8:4968, v8:4974
LOG=n
Review-Url: https://codereview.chromium.org/1941823003
Cr-Commit-Position: refs/heads/master@{#35957}
The ECMA 402 implementation previously pushed directly to real
Arrays, which risks having observably incorrect behavior in the
presence of monkey patching. This patch uses InternalArrays instead
to avoid that hazard.
R=jshin@chromium.org,yangguo@chromium.org
BUG=chromium:604299
LOG=N
Review-Url: https://codereview.chromium.org/1923803002
Cr-Commit-Position: refs/heads/master@{#35949}
Our implementation of the spec got one comparison wrong, at
step 19.d.iii (we were comparing against 'q' instead of 'p').
R=littledan@chromium.org
BUG=chromium:607566
LOG=n
Review-Url: https://codereview.chromium.org/1940643002
Cr-Commit-Position: refs/heads/master@{#35947}
The compilation pipeline is correctly guarding against accidental
tier-ups by now, the tests in question should no longer fail.
R=yangguo@chromium.org
BUG=v8:4961
LOG=n
Review-Url: https://codereview.chromium.org/1938983002
Cr-Commit-Position: refs/heads/master@{#35934}
Now ChangeLowering is only concerned with lowering memory access and
allocation operations, and all changes are consistently lowered during
the effect/control linearization pass. The next step is to move the
left over lowerings to a pass dedicated to eliminate redundant loads and
stores, eliminate write barriers, fold and inline allocations.
Drive-by-fix: Rename ChangeBitToBool to ChangeBitToTagged,
ChangeBoolToBit to ChangeTaggedToBit, and ChangeInt31ToTagged to
ChangeInt31ToTaggedSigned for consistency.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
Committed: https://crrev.com/ceca5ae308bddda166651c654f96d71d74f617d0
Cr-Commit-Position: refs/heads/master@{#35924}
Review-Url: https://codereview.chromium.org/1941673002
Cr-Commit-Position: refs/heads/master@{#35929}
Reason for revert:
[Sheriff] Breaks mac gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/5821
Original issue's description:
> [turbofan] Remove left-over change bits from ChangeLowering.
>
> Now ChangeLowering is only concerned with lowering memory access and
> allocation operations, and all changes are consistently lowered during
> the effect/control linearization pass. The next step is to move the
> left over lowerings to a pass dedicated to eliminate redundant loads and
> stores, eliminate write barriers, fold and inline allocations.
>
> Also remove the atomic regions now that we wire everything into the
> effect chain properly. This is an important step towards allocation
> inlining.
>
> Drive-by-fix: Rename ChangeBitToBool to ChangeBitToTagged,
> ChangeBoolToBit to ChangeTaggedToBit, and ChangeInt31ToTagged to
> ChangeInt31ToTaggedSigned for consistency.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
>
> Committed: https://crrev.com/ceca5ae308bddda166651c654f96d71d74f617d0
> Cr-Commit-Position: refs/heads/master@{#35924}
TBR=ishell@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/1942733002
Cr-Commit-Position: refs/heads/master@{#35927}
This adds ignition to the testing variants that are run on all
bots.
Failing tests can only be skipped with the NO_IGNITION
keyword in status files. Existing expectations for the
ignition_turbofan variant are all duplicated and use the
NO_IGNITION keyword as well now.
BUG=v8:4280
LOG=N
Committed: https://crrev.com/132c09ed619f23fb7c6d26a4e3552c703389eabd
Cr-Commit-Position: refs/heads/master@{#35865}
Review-Url: https://codereview.chromium.org/1804003002
Cr-Commit-Position: refs/heads/master@{#35926}
Now ChangeLowering is only concerned with lowering memory access and
allocation operations, and all changes are consistently lowered during
the effect/control linearization pass. The next step is to move the
left over lowerings to a pass dedicated to eliminate redundant loads and
stores, eliminate write barriers, fold and inline allocations.
Also remove the atomic regions now that we wire everything into the
effect chain properly. This is an important step towards allocation
inlining.
Drive-by-fix: Rename ChangeBitToBool to ChangeBitToTagged,
ChangeBoolToBit to ChangeTaggedToBit, and ChangeInt31ToTagged to
ChangeInt31ToTaggedSigned for consistency.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
Review-Url: https://codereview.chromium.org/1941673002
Cr-Commit-Position: refs/heads/master@{#35924}
