Port a330af0ed1
Original commit message:
The optimized code generated by Crankshaft cannot properly deal
with proxies (in the prototype chain), and there's probably no
point in trying to make that work^Wfast with Crankshaft at all.
TurboFan will handle that properly; Crankshaft just bails out
to fullcodegen, which then goes to the runtime, which should do
the right thing soon.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1496843004
Cr-Commit-Position: refs/heads/master@{#32583}
Fix several operations in the parser that rewrite constant expressions
to preserve knowledge regarding whether a value originally contained a ".".
This information is required to accurately validate Asm.js typing.
Making the assumption that if either side of a binary operation contains
a dot, that the rewritten expression should be treated as a double for
Asm.js purposes. This is a slight deviation from the spec (which
would forbid mix type operations).
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator, test-parsing
R=titzer@chromium.org,marja@chromium.org,aseemgarg@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1492123002
Cr-Commit-Position: refs/heads/master@{#32581}
I added a flag to the CallDescriptor which indicates that the native
stack should be used for a CallObject instead of the js stack on arm64.
Additionally I removed the use of EmitPrepareArguments because the
current implementation does not work when float and int parameters are
mixed. I plan to fix it in a future CL, because currently I have a
problem figuring out the type of a parameter.
R=titzer@chromium.org, v8-arm-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1494123002
Cr-Commit-Position: refs/heads/master@{#32577}
Extract ToBoolean hints from the fullcodegen code object and put them
into the ToBoolean nodes created by the AstGraphBuilder. We currently
do not yet consume this feedback, that will be done in a followup CL.
R=mstarzinger@chromium.org
BUG=v8:4583
LOG=n
Review URL: https://codereview.chromium.org/1494973002
Cr-Commit-Position: refs/heads/master@{#32576}
It's expensive to walk all shared function infos during the gc atomic pause. Instead, use WeakCells to implement this structure without manual clearing.
BUG=
Review URL: https://codereview.chromium.org/1478943003
Cr-Commit-Position: refs/heads/master@{#32567}
This moves the proper handling for the end node withing the constructed
graph into the RawMachineAssembler. This simplifies all assemblers and
makes the handling of {Start} and {End} symmetrical.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1493963003
Cr-Commit-Position: refs/heads/master@{#32563}
Adds implementation and tests for Inc and Dec to bytecode graph builder.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1499593002
Cr-Commit-Position: refs/heads/master@{#32562}
Reason for revert:
Suspect for crashing found, relanding for canary coverage.
Original issue's description:
> Revert of Do not remove write barriers for stores of old space references in most recent old space allocation. (patchset #1 id:1 of https://codereview.chromium.org/1478113002/ )
>
> Reason for revert:
> Broken canary. Trying to find out root cause.
>
> Original issue's description:
> > Do not remove write barriers for stores of old space references in most recent old space allocation.
> >
> > BUG=chromium:561449
> > LOG=n
> >
> > Committed: https://crrev.com/369778ec55a63ebe51e8fa8497edb5b681069b9b
> > Cr-Commit-Position: refs/heads/master@{#32368}
>
> TBR=ulan@chromium.org,bmeurer@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:561449
>
> Committed: https://crrev.com/da56525478f1820e3da629576ab61acc5f84daac
> Cr-Commit-Position: refs/heads/master@{#32406}
TBR=ulan@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:561449
Review URL: https://codereview.chromium.org/1493313002
Cr-Commit-Position: refs/heads/master@{#32555}
Reason for revert:
Suspect for crashing found, relanding for canary coverage.
Original issue's description:
> Revert of [heap] Remove eager shortcut in JSFunction visitor. (patchset #1 id:1 of https://codereview.chromium.org/1476223002/ )
>
> Reason for revert:
> Still investigating bad canary.
>
> Original issue's description:
> > [heap] Remove eager shortcut in JSFunction visitor.
> >
> > This removes an optimization in the static JSFunction visitor that
> > eagerly marked through to the SharedFunctionInfo for code flushing
> > candidates. This causes all processing in VisitJSFunction to be
> > side-stepped and hence might cause leaks.
> >
> > R=hpayer@chromium.org
> >
> > Committed: https://crrev.com/a29f0576c32e8fda90bf7ab19c6d170568150a7f
> > Cr-Commit-Position: refs/heads/master@{#32332}
>
> TBR=mstarzinger@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/672b49119b857c4f96234b03e48b4b60de256969
> Cr-Commit-Position: refs/heads/master@{#32463}
TBR=mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1486413006
Cr-Commit-Position: refs/heads/master@{#32554}
Between requesting finalization of incremental marking and the time where we handle the request in the stack guard, the current full GC may have finished. In that case the stack guard triggers to late and tries to finalize marking in a state where marking is not going on.
Note that a cleaner fix would be to express the finalization phase in a special marking phase. I will do that in a follow-up CL.
BUG=
Review URL: https://codereview.chromium.org/1493133003
Cr-Commit-Position: refs/heads/master@{#32552}
This drops the specific slot containing the new.target value from our
construct stub frames. This side-channel has been deprecated and will
no longer be accessed by any consumers.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1489353004
Cr-Commit-Position: refs/heads/master@{#32550}
Whenever the InstanceOfStub finds a proxy (either passed as object or
somewhere on the prototype chain), it should bailout to the
%HasInPrototypeChain runtime function, which will do the right thing
(soonish).
R=yangguo@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1492243003
Cr-Commit-Position: refs/heads/master@{#32549}
This passes the new.target value in a register instead of through a
side-channel via the construct stub. Note that this marks the last
consumer of said side-channel and the special slot in the construct
stub frame can be removed as a follow-up.
R=bmeurer@chromium.org,yangguo@chromium.org
TEST=mjsunit/es6/regress/regress-new-target-context
Review URL: https://codereview.chromium.org/1492793002
Cr-Commit-Position: refs/heads/master@{#32548}
It didn't support subclassing case at all and in non-subclassing case the runtime
allocation didn't do the slack tracking step.
BUG=chromium:563339
LOG=Y
Review URL: https://codereview.chromium.org/1488023002
Cr-Commit-Position: refs/heads/master@{#32547}
port 411c5b7fb0 (r32524)
original commit message:
Also remove the ResultMode from ToBooleanStub and always return true or
false and use the same mechanism in fullcodegen. This is in preparation
for adding ToBoolean hints to TurboFan.
Drive-by-fix: We can use the power of the ToBooleanIC in TurboFan now
that the ResultMode is gone (and the runtime always returns true or
false from the miss handler).
BUG=
Review URL: https://codereview.chromium.org/1500483002
Cr-Commit-Position: refs/heads/master@{#32543}
port 531dde9f80 (r32516)
original commit message:
The new step-in implementation no longer tries to predict the step-in
target, so we don't need the arguments count nor call type anymore.
BUG=
Review URL: https://codereview.chromium.org/1493993002
Cr-Commit-Position: refs/heads/master@{#32540}
The optimized code generated by Crankshaft cannot properly deal
with proxies (in the prototype chain), and there's probably no
point in trying to make that work^Wfast with Crankshaft at all.
TurboFan will handle that properly; Crankshaft just bails out
to fullcodegen, which then goes to the runtime, which should do
the right thing soon.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1492983002
Cr-Commit-Position: refs/heads/master@{#32539}