Port 022ea7e057
Original commit message:
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.
Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.
Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.
BUG=v8:3953
LOG=n
Review URL: https://codereview.chromium.org/998503002
Cr-Commit-Position: refs/heads/master@{#27117}
This reduces the size of the StackHandler by yet another word. We no
longer need to keep track of the frame pointer, as the stack walk will
be able to recalculate it.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/991893003
Cr-Commit-Position: refs/heads/master@{#27115}
None of these fields is used in Blink. Embedder always can implement them using existing API.
BUG=chromium:465651
LOG=Y
Review URL: https://codereview.chromium.org/983833006
Cr-Commit-Position: refs/heads/master@{#27113}
Doing a runtime call should always be better than totally giving up
(unless we have fullcode-only intrinsics, which we'll probably never
have).
BUG=v8:3947
LOG=n
Review URL: https://codereview.chromium.org/997543002
Cr-Commit-Position: refs/heads/master@{#27110}
This makes sure that the pending message location is only tracked by
the message object, as only this is saved for finally-blocks. The
location information is duplicated and becomes stale.
R=titzer@chromium.org
TEST=maeh, not so much.
Review URL: https://codereview.chromium.org/987353002
Cr-Commit-Position: refs/heads/master@{#27109}
There are no stale store buffer pointers anymore. The sweeper thread can not be in conflict with store buffer processing.
BUG=
Review URL: https://codereview.chromium.org/993983002
Cr-Commit-Position: refs/heads/master@{#27107}
The prototype of a class constructor function is read only. When we set
computed property names we were ignoring this and we were overriding the
property.
Since the prototype is the only possible own read only property on the
constructor function object we special case this so we do not have to
check this for every property in the class literal.
BUG=v8:3945
LOG=N
R=mstarzinger@chromium.org, dslomov@chromium.org
Review URL: https://codereview.chromium.org/985643003
Cr-Commit-Position: refs/heads/master@{#27106}
We can do that now since we have the invariant that the store buffer always has valid slots after marking.
BUG=
Review URL: https://codereview.chromium.org/991853002
Cr-Commit-Position: refs/heads/master@{#27105}
This reduces the size of the StackHandler by one word. We no longer
need to keep track of the code object, as the stack walk finds it.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/985803002
Cr-Commit-Position: refs/heads/master@{#27103}
We can remove a few of them now (those which unconditionally bailout),
but this will be done in a separate CL to see any impact separately.
BUG=v8:3947
LOG=n
Review URL: https://codereview.chromium.org/993963002
Cr-Commit-Position: refs/heads/master@{#27102}
Note that this patch is not really a *solution*, it is just enough to
make the undefined behavior unobservable. The real fix would be being
much more correct about sizes and signedness in our code base...
BUG=chromium:464657
LOG=n
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/995743002
Cr-Commit-Position: refs/heads/master@{#27100}
The bits in CompilerHints are accessed via FunctionKindBits, and on the other
hand, with accessors defined by BOOL_ACCESSORS(SharedFunctionInfo,
compiler_hints, is_accessor_function, kIsAccessorFunction) etc.
So the bit order in FunctionKind must match CompilerHints.
This is not causing problems (yet) because there's no accessor for these two
bits, but if somebody adds one, things will go wrong.
R=dslomov@chromium.org
BUG=
Review URL: https://codereview.chromium.org/988413002
Cr-Commit-Position: refs/heads/master@{#27096}
We use slightly different schema for JumpTable on arm64 than for x64.
We do a branch (B) to the JumpTable from the code,
then a branch (B) to the end of jump table code
and then branch to the deoptimizer code with putting
the return address into lr register (Call which is actually Blr).
As a result the 'from' address in Deoptimizer always points to
the end of JumpTable code and we can get nothing from this information.
0) I moved save_doubles and needs_frame code out of for_loop.
1) I replaced B commands with Bl so we put different return addresses
to lr register for the different jump table entries and replaced
the final Call with Br which do not touch lr register.
Also I removed the last_entry check so we will always do the Bl
even for the last entry because we need the right address in lr.
I don't think that this will affect the performance because it
just one more branch for entire deopt mechanics.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/984893003
Cr-Commit-Position: refs/heads/master@{#27094}
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.
Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.
Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.
BUG=v8:3953
LOG=n
R=yangguo@chromium.org,svenpanne@chromium.org
Review URL: https://codereview.chromium.org/990963003
Cr-Commit-Position: refs/heads/master@{#27086}
Context specialization enables inlining (at least currently it is the
only enabler for inlining), but inlining enables more possibilities for
context specialization. So we really need to run them together.
This is especially important with the "module based builtins" that we're
working towards.
BUG=v8:3952
LOG=n
Review URL: https://codereview.chromium.org/988423004
Cr-Commit-Position: refs/heads/master@{#27085}
since the old style weakness is slated for removal, we might as well reuse the name to limit confusion. additionally I simplified the callback type to a enum to either get internal field values or not
this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused.
R=jochen@chromium.org, erikcorry@chromium.org
BUG=
Review URL: https://codereview.chromium.org/989153003
Cr-Commit-Position: refs/heads/master@{#27084}
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).
BUG=
Review URL: https://codereview.chromium.org/974213002
Cr-Commit-Position: refs/heads/master@{#27078}
The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.
We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.
The test was reworked so it tests identical functions against different reasons.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/984773003
Cr-Commit-Position: refs/heads/master@{#27076}
After establishing the invariant that the store buffer always has valid slots after marking, the store buffer integrity check is not needed anymore.
BUG=454157
LOG=n
Review URL: https://codereview.chromium.org/990173002
Cr-Commit-Position: refs/heads/master@{#27073}
This makes sure only the %_DeoptimizeNow intrinsic is inlined, and
not the %DeoptimizeNow one. It hence re-establishes the invariant
that JSIntrinsicLowering only deals with inline intrinsics.
R=jarin@chromium.org
TEST=mjsunit/compiler/eager-deopt-simple
Review URL: https://codereview.chromium.org/988333003
Cr-Commit-Position: refs/heads/master@{#27070}
The JSInliner used to load the context from the JSFunction node at
runtime, which introduced a HeapConstant (because we had to materialize
the JSFunction after context specialization) and a LoadField operation,
independent whether the inlinee actually uses the context. This is
rather cumbersome currently, and therefore this is now changed to just
embed the context constant instead. Once we do inlining based on
SharedFunctionInfo rather than JSFunction, we should reconsider this
decision and come up with a proper heuristic.
BUG=v8:3952
LOG=n
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/994523002
Cr-Commit-Position: refs/heads/master@{#27069}
The store buffer can contain stale store buffer entries, i.e., slot in dead objects pointing to new space objects. These slots are treaded as live slots which cause problems with non-pointer fields and makes concurrent sweeping complicated. Removing these pointers from the store buffer before it is used makes life easier.
BUG=
Review URL: https://codereview.chromium.org/985453003
Cr-Commit-Position: refs/heads/master@{#27068}
