By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.
As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.
R=titzer@chromium.org, bmeurer@chromium.org
LOG=N
Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}
Reason for revert:
crashes: crbug.com/626719
Original issue's description:
> Avoid Context::Enter and Context::Exit if we're reentering the active and last entered context
>
> A bit of browsing around indicates that the new fast-path is taken most of the time:
> 3496 Entering new
> 152295 Reentering same
>
> BUG=
>
> Committed: https://crrev.com/1829eb661ef1cf432fb551bcb193f521a219d490
> Cr-Commit-Position: refs/heads/master@{#37570}
TBR=jochen@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2140563002
Cr-Commit-Position: refs/heads/master@{#37632}
CallSite::IsConstructor() was unable to recognize builtin construct stubs
(NumberConstructor_ConstructStub and StringConstructor_ConstructStub) as
constructors, and thus these frames were not formatted correctly in stack
traces.
Fix this by explicitly marking their Code objects as construct stubs and
passing along a special receiver value when we encounter such cases in
CaptureSimpleStackTrace.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2125163004
Cr-Commit-Position: refs/heads/master@{#37631}
If a Smi field load is truncated to Word32, we can just load the upper
32 bits on 64-bit architectures (with 32-bit Smis), which avoids the
nasty shift right that we'd have to perform otherwise to untag it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2140553002
Cr-Commit-Position: refs/heads/master@{#37630}
Usually loops run from 0 to some array length l, which means the
induction variable i will probably have type Unsigned32, just like
the length l. The CheckBounds operation lowers to an Uint32LessThan
comparison, so if we also lower the user level i < l comparison to
Uint32LessThan (whenever possible), we get some bounds check elimination
for free (via value numbering plus branch condition elimination).
This merges the branch condition elimination phase with the late
optimization phase to make this magic happen.
R=jarin@chromium.org
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2135123002
Cr-Commit-Position: refs/heads/master@{#37629}
This enables tests which verify allocation site feedback is used and
influences pretenuring decisions. By now TurboFan is respecting such
feedback. Ignition however doesn't provide such feedback yet.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2135563003
Cr-Commit-Position: refs/heads/master@{#37628}
This change analyzes and links the output of --code-comments in the disassembly view within turbolizer with the other views, such that selecting these comments will also select the respective blocks/lines/nodes within the other views. The block start comments (e.g. -- B4 start --) are linked with the blocks in the schedule phase view and vice versa. The source position comments (e.g. -- primes.js:3:10 --) select the respective spans, lines, and nodes in the JavaScript code view, the schedule phase view, and the other compilation phase views respectively, and vice versa. It also modifies the display of the line and column numbers in the source position comments to be offset from 1 instead of 0 and ignore the initial source position of the first line of code (from removal of the function name in the compiler).
Also fixed the bug where previous selections weren't being cleared properly across multiple views, adding appropriate clear calls when using the selection broker.
Review-Url: https://codereview.chromium.org/2133663002
Cr-Commit-Position: refs/heads/master@{#37627}
Enable the same checks for builtin exit frames as are used for all other
standard (i.e. non-wasm) types, and refactor them into a single helper
class.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2135593002
Cr-Commit-Position: refs/heads/master@{#37625}
Consume Smi/Signed32 feedback for division and modulus and introduce
appropriate checked operators. This is especially important for modulus
where the Float64Mod operator is significantly slower than Int32Mod on
most platforms. For division it's mostly important to propagate
integerness, i.e. to avoid follow-up conversions between float and
int32.
Drive-by-fix: Use Int32Mod for the ModulusStub (and the bytecode handler)
when the inputs are both Smi.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2138633002
Cr-Commit-Position: refs/heads/master@{#37621}
Rolling v8/build to 766297ee7fd0da3d95276a02ff11089ec3aced9b
Rolling v8/tools/clang to 29e654f4a3d0fa9c7c69f2967d427ccbd6f4d4c8
Rolling v8/tools/mb to c279952c34ea262021767ad1f2087f988d85881c
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2136463003
Cr-Commit-Position: refs/heads/master@{#37620}
The Intl code previously called the initial value of String.prototype.split
for some internal operations. However, this did not have the intended effect
as Intl only needs to split strings by strings, but String.prototype.split
has integration with Symbol.split for RegExps.
This patch replaces the calls of StringSplit in the Intl implementation
with direct calls to the %StringSplit runtime function to avoid the issue.
R=yangguo@chromium.org
BUG=v8:5179
Review-Url: https://codereview.chromium.org/2126073002
Cr-Commit-Position: refs/heads/master@{#37615}
Since Linux 4.1, flag -f became -F, but the long option --flags stayed
the same. Using --flags assures compatibility with new and old versions.
Also, symbols appear to be reported as name+offset in newer versions
even when not requested, so we trim the latter part if present.
BUG=v8:4899
LOG=N
Review-Url: https://codereview.chromium.org/2134703002
Cr-Commit-Position: refs/heads/master@{#37614}
Isolate is not going to retain a CPU profiler.
The client will be creating an instance of profiler when needed.
Deprectate v8::Isolate::GetCpuProfiler()
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2117343006
Cr-Commit-Position: refs/heads/master@{#37613}
Reason for revert:
This workaround is no longer needed, port of e60c4053c7 fixes the issue.
Original issue's description:
> MIPS: [turbofan] Fix addition for deoptimization.
>
> In turbofan, after an addition operation where the same register is the
> output and both inputs, if deoptimization is performed the input is
> overwritten with the output value and the final result is not correct.
> This is fixed by restoring the original value of the input before
> deoptimization.
>
> BUG=
> TEST=mjsunit/regress/regress-int32-truncation
>
> Committed: https://crrev.com/99385e8e4bcef1f333ede61c936528bfc0c8ecfa
> Cr-Commit-Position: refs/heads/master@{#37524}
TBR=akos.palfi@imgtec.com,balazs.kilvady@imgtec.com,ivica.bogosavljevic@imgtec.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2129083003
Cr-Commit-Position: refs/heads/master@{#37612}
This removes the frame state input representing the before-state from
nodes having the {JSDivide} or the {JSModulus} operator. Lowering that
inserts number conversions of the inputs has to be disabled when
deoptimization is enabled, because the frame state layout is no longer
known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2121153003
Cr-Commit-Position: refs/heads/master@{#37608}
This CL is on the way to extend parallel compilation of wasm modules to code generation. With parallel compilation it is not allowed to dereference handles during code generation. However, the is_identical_to check dereferences handles. In this CL we therefore replace the call to is_identical_to with a handle comparison.
Review-Url: https://codereview.chromium.org/2109143002
Cr-Commit-Position: refs/heads/master@{#37607}
This enables tests which rely on the context available at "debugger"
statements to be accurate. This is the case by now when deoptimization
information is available.
R=yangguo@chromium.org
BUG=v8:4055
Review URL: https://codereview.chromium.org/2129123002 .
Cr-Commit-Position: refs/heads/master@{#37604}
Reason for revert:
Performance stayed the same after the revert; relanding.
Original issue's description:
> Revert of [esnext] ship --harmony-object-values-entries (patchset #1 id:1 of https://codereview.chromium.org/2116053003/ )
>
> Reason for revert:
> Revert to see if it addresses the performance regression observed in chromium:625956 in automated graphs
>
> Original issue's description:
> > [esnext] ship --harmony-object-values-entries
> >
> > BUG=v8:4663
> > R=littledan@chromium.org, adamk@chromium.org
> >
> > Committed: https://crrev.com/ab529234853a1768642f8f6c907aaaa5ea8b19bf
> > Cr-Commit-Position: refs/heads/master@{#37485}
>
> TBR=adamk@chromium.org,caitpotter88@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:4663
>
> Committed: https://crrev.com/1177750a98faaa11e92ece13b70115bf704baf3b
> Cr-Commit-Position: refs/heads/master@{#37566}
TBR=adamk@chromium.org,caitpotter88@gmail.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4663
Review-Url: https://codereview.chromium.org/2127253002
Cr-Commit-Position: refs/heads/master@{#37596}
Drive-by-fix: hydrogen code does not blindly return the
byteLength offset, instead it executes what is defined
in the byteLength getter.
BUG=
Review-Url: https://codereview.chromium.org/2123263002
Cr-Commit-Position: refs/heads/master@{#37595}
Such an object can be used to later create a context from it. It has to
have access checks with handlers enabled, as it cannot be accessed
otherwise.
BUG=chromium:618305
R=verwaest@chromium.org
Review-Url: https://codereview.chromium.org/2107673003
Cr-Commit-Position: refs/heads/master@{#37594}
This enables tests which rely on the context available at "debugger"
statements to be accurate. This is the case by now when deoptimization
information is available.
R=mvstanton@chromium.org
BUG=v8:4035
Review-Url: https://codereview.chromium.org/2125773005
Cr-Commit-Position: refs/heads/master@{#37590}
Port de369129d2
Original commit message:
In the current implementation of wasm an unrepresentable input of the
float32-to-int32 conversion is detected by first truncating the input, then
converting the truncated input to int32 and back to float32, and then checking
whether the result is the same as the truncated input.
This input check does not work on arm and arm64 for an input of (INT32_MAX + 1)
because on these platforms the float32-to-int32 conversion results in INT32_MAX
if the input is greater than INT32_MAX. When INT32_MAX is converted back to
float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be
represented precisely as float32, and rounding-to-nearest results in (INT32_MAX
+ 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears
to be representable.
With the changes in this CL, the result of the float32-to-int32 conversion is
incremented by 1 if the original result was INT32_MAX. Thereby the detection of
unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be
represented precisely in float32, it can also never be a valid result of the
float32-to-int32 conversion.
BUG=cctest/test-run-wasm/RunWasmCompiled_I32SConvertF32,cctest/test-run-wasm/RunWasmCompiled_I32UConvertF32
Review-Url: https://codereview.chromium.org/2130763002
Cr-Commit-Position: refs/heads/master@{#37586}
Now LookupIterator follows the same pattern of prepare transition, apply transition
and write value when adding new properties to dictionary objects.
JSGlobalObject case:
* Prepare transition phase ensures that there is a "transition" property cell
prepared for receiving a value.
* Apply transition phase does nothing.
* Prepare for data property phase ensures that the existing property cell can
receive the value.
* Write value phase writes value directly to the current property cell.
JSObject case:
* Prepare transition phase prepares the object for receiving a data value (which
could switch an object to dictionary mode).
* Apply transition phase migrates object to a transition map. If the map happened
to be a dictionary mode object's map then an uninitialized entry added to the
properties dictionary.
* Prepare for data property phase does nothing.
* Write value phase just puts value to the properties dictionary.
BUG=chromium:576312
Review-Url: https://codereview.chromium.org/2127583002
Cr-Commit-Position: refs/heads/master@{#37585}
