The TurboFan backends currently don't support tail-calls to CPP builtins
because the semantics of kJavaScriptCallArgCountRegister has different
semantics for stub call descriptors versus JavaScript call descriptors.
This is actually a short-coming of the backends and follow-up work will
make the backends more robust in that regard to fail hard on unsupported
constructs like that. This just disables the lowering creating such a
tail-call.
R=bmeurer@chromium.org
BUG=chromium:658691
TEST=mjsunit/regress/regress-crbug-658691
Review-Url: https://codereview.chromium.org/2447383002
Cr-Commit-Position: refs/heads/master@{#40590}
This patch replaces it with calls to the runtime function and PromiseSet.
This allows us to move PromiseReject to C++ without regressions.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2451133002
Cr-Commit-Position: refs/heads/master@{#40589}
The tail-call operator for invoking a JSFunction object from within stub
code has been dead for a while and untested by now. This removes support
for such a construct.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2452943002
Cr-Commit-Position: refs/heads/master@{#40583}
Reason for revert:
Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
Original issue's description:
> [compiler] Properly validate stable map assumption for globals.
>
> For global object property cells, we did not check that the map on the
> previous object is still the same for which we actually optimized. So
> the optimized code was not in sync with the actual state of the property
> cell. When loading from such a global object property cell, Crankshaft
> optimizes away any map checks (based on the stable map assumption),
> leading to arbitrary memory access in the worst case.
>
> TurboFan has the same bug for stores, but is safe on loads because we
> do appropriate map checks there. However mixing TurboFan and Crankshaft
> still exposes the bug.
>
> R=yangguo@chromium.org
> BUG=chromium:659475
TBR=yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2454513003
Cr-Commit-Position: refs/heads/master@{#40582}
The original reason for the extra output on windows is
obsolete since a while. Now the extra output just spams
the logs and causes traffic.
BUG=chromium:485932
Review-Url: https://codereview.chromium.org/2452763003
Cr-Commit-Position: refs/heads/master@{#40580}
Native setters (see AccessorInfo in accessors.h) didn't have the ability
to return a result value. As a consequence of this, for instance, Reflect.set
on the length property of arrays had the wrong behavior:
var y = [];
Object.defineProperty(y, 0, {value: 42, configurable: false})
Reflect.set(y, 'length', 0)
The Reflect.set call used to return true. Now it returns false as
required by the spec.
BUG=v8:5401
Review-Url: https://codereview.chromium.org/2397603003
Cr-Commit-Position: refs/heads/master@{#40579}
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40578}
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.
Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).
This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2449353002
Cr-Commit-Position: refs/heads/master@{#40577}
Fix failing assertions in the CodeStubAssembler that cause Object.create(null,
global) fail.
Drive-by-fix: convert some Assert to CSA_ASSERT.
BUG=chromium:657692
Review-Url: https://codereview.chromium.org/2446203003
Cr-Commit-Position: refs/heads/master@{#40576}
A GC might cause the just created dictionary object to have an invalid backing
store, which breaks heap verification.
BUG=chromium:659088
Review-Url: https://codereview.chromium.org/2452653002
Cr-Commit-Position: refs/heads/master@{#40574}
For Math builtins that likely yield double results, i.e. Math.sin,
Math.cos and friends, don't bother trying to canonicalize the result
to Smi. The rationale behind this is that other parts of V8 use the
HeapNumber representation as a hint to assume that certain values
should be represented as double (i.e. for the array elements kind
and for double field tracking). This way the chance that we make
the ideal decision early on is better.
For Math.abs we establish the contract that if the input value is a
Smi, then we try hard to return a Smi (doesn't work for minimal Smi
value), otherwise we preserve the HeapNumberness of the input.
Same for the generic Add, Subtract, Multiply, etc. code stubs.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2451973003
Cr-Commit-Position: refs/heads/master@{#40573}
This causes a 3.1% regression because we unconditionally call out to a
runtime function.
This patch refactors out most of EnqueuePromiseReactionJob
runtime function into a separate function.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2449053003
Cr-Commit-Position: refs/heads/master@{#40570}
Emit the compare and branch on zero (CBZ) instruction when
possible for deoptimisations, as we do for normal branches.
BUG=
Review-Url: https://codereview.chromium.org/2448113002
Cr-Commit-Position: refs/heads/master@{#40568}
This lets us investigate regressions caused by this marking while
letting others continue their work without being impacted.
BUG=v8:5512
Review-Url: https://codereview.chromium.org/2446673002
Cr-Commit-Position: refs/heads/master@{#40563}
Removes PromiseEnqueue and moves debugging code to a separate
function which gets called when the debugger is active.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2450763002
Cr-Commit-Position: refs/heads/master@{#40562}
This is a partial revert of 438c5eb28b to avoid huge increases in
testing times due to expensive bytecode handler generation in debug
modes. The additional coverage does not warrant a 2x to 3x increase
in testing time at the moment. We can revisit this later.
TBR=rmcilroy@chromium.org
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2445403002
Cr-Commit-Position: refs/heads/master@{#40558}
This brings the BytecodeGenerator in line with FullCodeGenerator, now that
more requests for hole checks are flowing through BuildVariableAssignment.
BUG=chromium:658528
Review-Url: https://codereview.chromium.org/2447783002
Cr-Commit-Position: refs/heads/master@{#40557}
FulfillPromise is always called when a promise is in a pending state
which makes this check redundant.
Review-Url: https://codereview.chromium.org/2442373002
Cr-Commit-Position: refs/heads/master@{#40556}
This makes sure that bytecode handlers are regenerated when debugging
code within handlers is being requested. We cannot use the handlers
baked into the snapshot in this case.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2443923002
Cr-Commit-Position: refs/heads/master@{#40555}
Object.create(null) is most likely to be used for dictionary-like objects.
Hence it would be beneficial to directly create a slow-mode object and avoid
additional overhead later-on.
BUG=
Review-Url: https://codereview.chromium.org/2430273007
Cr-Commit-Position: refs/heads/master@{#40551}
The interpreter is currently too aggressive in tiering up to TurboFan,
especially for (expensive) OSR. Make it slightly less aggressive by
choosing a more realistic code size multiplier.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2448043002
Cr-Commit-Position: refs/heads/master@{#40550}
This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:
* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2448463002
Cr-Commit-Position: refs/heads/master@{#40547}
To achieve this:
- fixed crash on windows - String16::fromInteger used "%zu" which doesn't support by VS2013 compiler, wrapped with ifdef else.
- fixed asan for d8 - unique_ptr on array has single element type.
- force Debugger.disable at the end of test.
BUG=chromium:635948
R=dgozman@chromium.org,yangguo@chromium.org,machenbach@chromium.org
Review-Url: https://codereview.chromium.org/2450653002
Cr-Commit-Position: refs/heads/master@{#40546}
Don't inline the full StringFromCharCode logic into TurboFan, but only
the common case, and use the %StringFromCharCode runtime function for
the rest, similar to what we do in HStringCharFromCode in Crankshaft.
This greatly reduces compile time for TurboFan due to greatly reduced
number of nodes. For example it reduces overall runtime of the base64
benchmark by up to 15% with the future pipeline.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2445273002
Cr-Commit-Position: refs/heads/master@{#40544}
Modify the Bytecode Register Optimizer to be an independent component
rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder
can explicitly call it with register operands when outputting a bytecode
and the Bytecode Register Optimizer doesn't need to work out which operands
are register operands. This also means we don't need to build BytecodeNodes
for Ldar / Star / Mov bytecodes unless they are actually emitted by the
optimizer.
This change also modifies the way the BytecodeArrayBuilder converts
operands to make use of the OperandTypes specified in bytecodes.h.
This avoids having to individually convert operands to their raw output
value before calling Output(...).
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2393683004
Cr-Commit-Position: refs/heads/master@{#40543}
Now we
- always set .result to undefined before a visited loop and switch since we can't know whether they will set a value,
- only visit finally if it can break/continue; and only store/restore .result in that case
BUG=
Review-Url: https://codereview.chromium.org/2427253003
Cr-Commit-Position: refs/heads/master@{#40542}
CL https://codereview.chromium.org/2177273002 changed FastNewFunctionContextStub
to take a number of slots parameter and in-doing so removed the maximum slot
count for FastNewFunctionContextStub. This made it possible to create a
closure which is larger than kMaxRegularHeapObjectSize and so can't be
allocated by FastNewFunctionContextStub.
Reintroduce FastNewFunctionContextStub::kMaxSlots (but make the limit much
larger) to ensure we call the runtime for contexts which need to be
allocated in the LO space.
BUG=chromium:655573
Review-Url: https://codereview.chromium.org/2445703002
Cr-Commit-Position: refs/heads/master@{#40541}
