With this change, we remember the types of frame state inputs (in a new
operator, called TypedStateValues). Instead of inferring the value types
when building translations, we used the recorded types.
The original approach was not reliable because the passes after
simplified lowering can change node types, and this in turn confuses
the translation builder.
BUG=chromium:468727
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1015423002
Cr-Commit-Position: refs/heads/master@{#27310}
The CallInterfaceDescriptor already provides information about the
expected representation of parameters, so we can use that instead of
hardcoding tagged representation for all parameters.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1019293002
Cr-Commit-Position: refs/heads/master@{#27308}
Reason for revert:
Failing Blink tests on Win and Mac:
- plugins/netscape-plugin-property-access-exception.html
- http/tests/plugins/cross-frame-object-access.html
Original issue's description:
> Cleanup and unify Isolate::ReportPendingMessages.
>
> Note that this is a pure cleanup CL and shouldn't have an observable
> impact on the functional behavior of message reporting.
>
> R=yangguo@chromium.orgTBR=yangguo@chromium.org,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1016323002
Cr-Commit-Position: refs/heads/master@{#27306}
Add support for appending extend modes uxtb or uxth to add and subtract
instructions, and using them in the instruction selector.
BUG=
Review URL: https://codereview.chromium.org/1021533002
Cr-Commit-Position: refs/heads/master@{#27303}
Use a delegating constructor for CompilationInfo, reducing duplicated
code. Simplified handling of InlinedFunctionInfos on the way: When we
start compiling, we have bigger things to worry about than a default
vector.
Reduced the usage of a SharedFunctionInfo for compiling, this is a
slighty strange concept.
Review URL: https://codereview.chromium.org/1018853004
Cr-Commit-Position: refs/heads/master@{#27299}
If the Maybe is nothing or the MaybeLocal is empty, it means that the
API call either threw an exception or an exception was already pending.
In that case, the embedder needs to handle the exception or otherwise
react to the failed API call.
BUG=v8:3929
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1022803002
Cr-Commit-Position: refs/heads/master@{#27298}
The weaken limits are constants, there's no point in having a separate
copy of those constants per typer that is initialized per Typer
instance.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1008923004
Cr-Commit-Position: refs/heads/master@{#27297}
This reduces the overhead of typed lowering, because we lower
JSToBoolean/JSUnaryNot directly if possible, instead of first lowering
to AnyToBoolean, and then letting the SimplifiedOperatorReducer do the
further lowering.
Also remove some obsolete tests from the cctest suite that have since
been removed by proper unittests. And improve unitttest coverage for the
typed lowering cases.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/999173003
Cr-Commit-Position: refs/heads/master@{#27295}
When the debugger is active, a host of connected functions get an associated
DebugInfo structure, and their code is copied. The debugger uses the original
code to occasionally patch ICs with their initial value. Although IC learning
can occur, it's thrown away often, depending on the constellation of
breakpoints active or deactivating. Finally, feedback is discarded when the
debugger is turned off.
The type feedback vector needs to be brought into line with this behavior, so
now the debugger clears it's IC slots at appropriate bottlenecks in debug.cc.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1014373002
Cr-Commit-Position: refs/heads/master@{#27289}
The control input is only relevant for operations that may "write" (to
prevent hoisting) or "throw" (because they are part of the control chain).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1015353004
Cr-Commit-Position: refs/heads/master@{#27288}
Updated excludes to remove SKIPs where possible. Either
removing if no longer needed or replacing with SLOW where
tests just need more time to run
modified: test/cctest/cctest.status
modified: test/mjsunit/mjsunit.status
R=danno@chromium.org, svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1017073003
Cr-Commit-Position: refs/heads/master@{#27287}
The change introduces a second frame state (for the state before
the operation) for the StoreProperty nodes. If the store writes
into a typed array, the frame state is used for lazy deopt from
the to-number conversion that is performed by the store.
BUG=v8:3963
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/997983004
Cr-Commit-Position: refs/heads/master@{#27285}
Port 16c8485a35
Original commit message:
Replaces StoreGlobalCell / LoadGlobalCell with NamedField variants that use write barriers.
BUG=
Review URL: https://codereview.chromium.org/1014293002
Cr-Commit-Position: refs/heads/master@{#27277}
Port 15f8213809
Original commit message:
This relands commit 96f79568a9.
This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.
There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.
With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.
BUG=
Review URL: https://codereview.chromium.org/1015993002
Cr-Commit-Position: refs/heads/master@{#27273}
I found some strange split in deopt entry points generator.
The code for table entry generator had two classes.
It is safe to join these classes together and drop virtual.
BUG=
LOG=n
Review URL: https://codereview.chromium.org/1010413003
Cr-Commit-Position: refs/heads/master@{#27264}
This relands commit 96f79568a9.
This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.
There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.
With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/997213003
Cr-Commit-Position: refs/heads/master@{#27263}
Some native counters (e.g. KeyedLoadGenericSlow) are referenced from stubs that are generated very early in the Isolate lifecycle before v8::Isolate::New returns. Thus counter lookup callback also needs to be installed early prior to v8::internal::Isolate::Init call. Otherwise assembler will just assume that the counter is not enabled and produce no code from IncrementCounter - because address of the counter is not yet available.
Histogram related callbacks are moved for consistency to make them able to collect samples which occur at isolate initialization time.
BUG=
Review URL: https://codereview.chromium.org/1010233002
Cr-Commit-Position: refs/heads/master@{#27262}
