Code common with ObjectHasOwnProperty builtin was moved to CodeStubAssembler.
BUG=v8:2743
LOG=Y
Review-Url: https://codereview.chromium.org/1894953004
Cr-Commit-Position: refs/heads/master@{#35972}
Adapts FastCloneShallowObjectStub to enable it to be used by the
CreateObjectLiteral bytecode.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1922523002
Cr-Commit-Position: refs/heads/master@{#35909}
Instead of replacing the array with an empty one after resuming, overwrite
contents with a new Oddball.
This will simplify the work to be done by the bytecode graphbuilder and
potentially allow for more optimization.
(For full-codegen generators, nothing changes.)
BUG=v8:4907
LOG=n
Review-Url: https://codereview.chromium.org/1923253002
Cr-Commit-Position: refs/heads/master@{#35872}
Now that the GC team has landed the appropriate changes to ensure that the top
page of the address space is never used for allocation, the inlined fast-case
allocation path in the CodeAssembler can be micro-optimized to an add to top
followed by an unsigned compare to limit, eliding a no-longer-needed overflow
check.
Review-Url: https://codereview.chromium.org/1923803003
Cr-Commit-Position: refs/heads/master@{#35830}
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1919513002
Cr-Commit-Position: refs/heads/master@{#35743}
Need to use the kHashFieldSlot rather than kHashFieldOffset for
pointer-sized memory accesses.
(Fix for "[builtins] Migrate String.prototype.charCodeAt and String.prototype.charAt to TurboFan.")
R=bmeurer@chromium.org, epertoso@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1907393002
Cr-Commit-Position: refs/heads/master@{#35741}
The new bytecodes replace two runtime functions. They are still unsupported by the bytecode graphbuilder, though.
BUG=v8:4907
LOG=n
Review URL: https://codereview.chromium.org/1904933002
Cr-Commit-Position: refs/heads/master@{#35716}
This operator doesn't generate any actual code, but teaches the register
allocator that a certain computed pointer value is tagged. This is
required to safely implement InnerAllocate (and we also use this for
Allocate to be sure that we don't suddenly leak a dangling pointer into
the heap somewhere).
R=epertoso@chromium.org
BUG=v8:4939
LOG=n
Review URL: https://codereview.chromium.org/1905813003
Cr-Commit-Position: refs/heads/master@{#35700}
This separation is needed to make two goals possible simultaneously:
* is should be possible to offer V8 components a simple, clean
interface to TurboFan's low-level code generation that doesn't
expose details about the TF.
* it should be possible to easily create new CodeAssembler "macros"
that don't require a review from an OWNER of the compiler directory.
Review URL: https://codereview.chromium.org/1875583003
Cr-Commit-Position: refs/heads/master@{#35576}
