On the debug info, we have a list of existing break points. When we
step in the debugger, we flood the function with one-shot break points.
Afterwards, we clear these one-shots by clearing all break locations.
Previously, while clearing break locations, we would skip ones that have
actual break points. Now we clear all break locations, and then reapply
break points. This is necessary for the next step, when we encode break
point info by source position, and not code offset. Encoding by code
offset would mean that break points are dependent on the code kind we
use.
R=jgruber@chromium.org
BUG=v8:5265
Review-Url: https://codereview.chromium.org/2221333002
Cr-Commit-Position: refs/heads/master@{#38492}
When we compile a growing store in TurboFan, we don't pass a (native)
context to the %GrowArrayElements fallback function, as the whole logic
is actually context independent. However, that means that we need to
bailout early in case the object is a prototype, which requires context
dependent checks in the array protector code.
R=cbruni@chromium.org
BUG=chromium:635798
Review-Url: https://codereview.chromium.org/2224253003
Cr-Commit-Position: refs/heads/master@{#38491}
Reason for revert:
crashing on ToT
Original issue's description:
> [heap] Enable black allocation when finalizing incremental marking.
>
> BUG=chromium:630386
>
> Committed: https://crrev.com/bb4e028648a27a6958afc9b5040366b899cda50d
> Cr-Commit-Position: refs/heads/master@{#38487}
TBR=mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:630386
Review-Url: https://codereview.chromium.org/2223423003
Cr-Commit-Position: refs/heads/master@{#38490}
We lowered JSConvertReceiver using JSToObject, w/o connecting the
JSToObject to the control chain (which is fine since that ToObject
cannot throw). But then the lowering of the JSToObject would insert
an IfSuccess, which is immediately dead, since it is not used. This
was fine in a sense that it didn't seem to crash anything, but we
now want to do more aggressive checking if IfSuccess/IfException
nodes and so we need to fix this sloppyness in the lowerings.
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2228783003
Cr-Commit-Position: refs/heads/master@{#38484}
Avoids the always generated Star bytecodes after ObjectLiteral.
BUG=v4:4820
LOG=n
Review-Url: https://codereview.chromium.org/2216023003
Cr-Commit-Position: refs/heads/master@{#38480}
Previously, we would output \x5c to escape a backslash, but this is
invalid JSON and it would crash Turbolizer. Use \u005c instead.
BUG=
Review-Url: https://codereview.chromium.org/2224913002
Cr-Commit-Position: refs/heads/master@{#38479}
Use common CodeStubAssembler routines for FixedArray-copying builtin.
Also cleanup a few shared pieces of code along the way.
BUG=chromium:608675
Review-Url: https://codereview.chromium.org/2220673002
Cr-Commit-Position: refs/heads/master@{#38478}
- Remove Declaration::initialization(), move logic into parser.
The backends should only care about the actual initialization flag on the
variable.
- Introduce DeclareVariable convenience function that covers most cases of
variable declarations.
R=adamk@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2223843002
Cr-Commit-Position: refs/heads/master@{#38477}
These were the final remnants of error code written in JavaScript.
BUG=
Review-Url: https://codereview.chromium.org/2222893002
Cr-Commit-Position: refs/heads/master@{#38475}
Reason for revert:
Times out webgl errors: https://bugs.chromium.org/p/chromium/issues/detail?id=635545
Original issue's description:
> [KeyedLoadIC] Support Smi "handlers" for element loads
>
> This is an experiment as far as performance is concerned. If Smi-configured
> element loading directly from the dispatcher stub is fast enough, then we
> can stop compiling LoadFastElementStubs (and drop the corresponding code).
>
> Committed: https://crrev.com/c9308147b341596de2733039223918a6202afa5f
> Cr-Commit-Position: refs/heads/master@{#38377}
BUG=chromium:635545
TBR=ishell@chromium.org,jkummerow@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2222273003
Cr-Commit-Position: refs/heads/master@{#38473}
Sanitize the typing rules for the various supported Math builtins, and
add appropriate typing rules for various Number, String, Object and global
builtins as well.
R=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2222053002
Cr-Commit-Position: refs/heads/master@{#38472}
Rolling v8/build to a348ac1d0bd4d6f42bf36f88904a52da2df9d899
Rolling v8/buildtools to 33a32b8aa2b7274d246fcf85ce8f762cf4291418
Rolling v8/tools/clang to 29b1d8ac90f12e64aa1604a14486f5ef383fe29e
Rolling v8/tools/mb to 7bf9c40acdef35ded30efc4b237d2d3946842126
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2223183003
Cr-Commit-Position: refs/heads/master@{#38469}
port 6768456db5 (r38395)
original commit message:
The old code was using VariableMode, but that signal is both
over-pessimistic (some CONST and LET variables need no hole-initialization)
and inconsistent with other uses of the InitializationFlag enum (such
as %LoadLookupSlot).
This changes no observable behavior, but removes unnecessary hole
initialization and hole checks in a few places, including
block-scoped function declarations, super property lookups,
and new.target.
BUG=
Review-Url: https://codereview.chromium.org/2223803002
Cr-Commit-Position: refs/heads/master@{#38468}
Collect type feedback for subtract operation in interpreter. Also use it in
bytecode-graph-bulder to set the correct Hint for subtract operation.
BUG=v8:5273
LOG=N
Review-Url: https://codereview.chromium.org/2221833002
Cr-Commit-Position: refs/heads/master@{#38467}
port eb84126923 (r38371)
original commit message:
One caveat: the Crankshaft stub used to preserve callee-clobbered double
registers, which is contrary to any real platform ABI that we support. Since the
only current use of this stub is in Crankshaft, the instruction there now must
be marked as double-clobbering. This might result in a small performance
regression. However, when this stub is eventually used in TF-generated code, it
will be called from deferred code that can save doubles only on the rarely-taken
path... something that Crankshaft can't do.
BUG=
Review-Url: https://codereview.chromium.org/2226673002
Cr-Commit-Position: refs/heads/master@{#38465}
port f68059b73a (r38383)
original commit message:
Benedikt, do you think we could also provide these operators on mips,
maybe by expanding them to "-0.0 -x"? If mips can provide these operators,
then we could make Float64Neg and Float32Neg real operators and not just
OptionalOperators.
BUG=
Review-Url: https://codereview.chromium.org/2223793002
Cr-Commit-Position: refs/heads/master@{#38464}
While we might at some point want to explore if this is a win versus
whole modules, for now we have the Tables interface planned.
R=titzer@chromium.org,ahaas@chromium.org,mtrofin@chromium.org,rossberg@chromium.org
BUG=v8:5044
Review-Url: https://codereview.chromium.org/2226053002
Cr-Commit-Position: refs/heads/master@{#38461}
This avoids direct access to scope() for later lazy scope allocation.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2225773003
Cr-Commit-Position: refs/heads/master@{#38458}
%InitializeConstGlobal has been dead code since the demise of legacy const
declarations. While getting rid of that call, also cleaned up and clarified
the surrounding code in a variety of ways.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2219223002
Cr-Commit-Position: refs/heads/master@{#38457}
To be able to lazily allocate BlockScopes, we need to reduce access to scope(). The explicit accesses removed here just need access to the current scope to allocate unresolved variable proxies. Those in the future should go over ScopeState rather than directly to Scope.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2224843003
Cr-Commit-Position: refs/heads/master@{#38456}
This removes the "resolve" parameter from Declare, since there's no case
where Scope analysis wouldn't make the same resolution decision the
parser can make here.
Other cleanup includes:
- Replace some if statements with DCHECKS where they could never be hit
- After the above, reordered some conditions for clarity
- Remove or edit down old comments
Should be no change in behavior.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2217973003
Cr-Commit-Position: refs/heads/master@{#38454}
