This is the only user of outer_scope_calls_sloppy_eval. Inlining it simplifies scope analysis.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2263123002
Cr-Commit-Position: refs/heads/master@{#38779}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
Committed: https://crrev.com/d7c6195c4c5cdc080caa74dfe2ae9ecab69bea73
Review-Url: https://codereview.chromium.org/2240463002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#38662}
Cr-Original-Original-Commit-Position: refs/heads/master@{#38668}
Cr-Original-Commit-Position: refs/heads/master@{#38725}
Cr-Commit-Position: refs/heads/master@{#38778}
This makes us able to get rid of dependencies to parser.h from places
which only need the ParseInfo, and also gets rid of the curious Parser
<-> Compiler circular dependency.
Also IWYUd where necessary.
BUG=
Review-Url: https://codereview.chromium.org/2268513002
Cr-Commit-Position: refs/heads/master@{#38777}
This fixes the uncommon fallback when Compiler::CompileOptimized fails
creating optimized code and also the underlying SharedFunctionInfo is
not compiled. We make sure not to uselessly regenerate the bytecode.
R=rmcilroy@chromium.org
BUG=chromium:639753
Review-Url: https://codereview.chromium.org/2261123002
Cr-Commit-Position: refs/heads/master@{#38776}
AstGraphBuilder overrides Visit(Expression*) to ensure that even if there is a
stack overflow, a value still gets produced. However, if there was no stack
overflow in the overriden function, but calling
AstVisitor<AstGraphBuilder>::Visit(expr) pushes us over the stack limit, then
the stack overflow check in that function will return without visiting the
expression, and the result will never get pushed.
To fix this, we add a new VisitNoStackOverflowCheck function which avoids the
inner stack check, and call that instead.
Since this depends on the size of C++ stack frames, there is no reliable test
I can add, however regress-635429.js exibits this behavior after
https://codereview.chromium.org/2240463002/ lands.
Review-Url: https://codereview.chromium.org/2262703002
Cr-Commit-Position: refs/heads/master@{#38774}
This detects loops with integer decrements.
Drive-by fix: Add lower bounds to lower_bounds
zone vector instead of upper_bounds.
BUG=
Review-Url: https://codereview.chromium.org/2260153002
Cr-Commit-Position: refs/heads/master@{#38772}
Now it just relies on NeedsContext and hence is guaranteed to be in sync.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2262133002
Cr-Commit-Position: refs/heads/master@{#38771}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control.
Fixing it:
- Don't include stuff in headers unless necessary.
- Include the stuff you need, not some other stuff that happens to include the
stuff you need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2258603003
Cr-Commit-Position: refs/heads/master@{#38770}
This adds cached versions of the DeoptimizeIf, DeoptimizeUnless and
Deoptimize operators that occur most often in various benchmarks.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2266743002
Cr-Commit-Position: refs/heads/master@{#38769}
Rolling v8/build to 3345815406d21b1ec594b95711ade879fa486241
Rolling v8/tools/clang to 781e8b3df3bbd631eae9560c1175aec8ce77f77d
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2266723002
Cr-Commit-Position: refs/heads/master@{#38768}
parser and the preparser, so that they contain the same set of methods,
with the same signatures. It mainly flags some traits methods as const.
It also contains a small cosmetic change in the definition of CHECK_OK.
R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2258123002
Cr-Commit-Position: refs/heads/master@{#38767}
This patch simply reorders the elements of classes ParserTraits
and PreParserTraits (mainly method headers), so that in both
classes the elements are defined in the same order. This is
useful for easily verifying the consistency between these two
classes.
R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2264483003
Cr-Commit-Position: refs/heads/master@{#38766}
Rolling v8/build to 38a9cfaa10bf2b91c52f8a9ef4449723dd7aa706
Rolling v8/tools/mb to 99788b8b516c44d7db25cfb68695bc234fdee5ed
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2267513002
Cr-Commit-Position: refs/heads/master@{#38765}
This patch subsumes CoverInitializedNameProduction to create an ObjectLiteralProduction which is now used to report the duplicate proto error as well.
This patch also changes ObjectLiteralChecker::CheckProperty
to record an ObjectLiteralProduction error instead of
bailing out immediately. Once we realize that we're in a
pattern, we rewind the error, otherwise we report the
error.
BUG=v8:5121
Review-Url: https://codereview.chromium.org/2255353002
Cr-Commit-Position: refs/heads/master@{#38764}
Also removed the "StandardProductions" enum value as its name is unhelpful
in deciding when to use it (and it only had a single reference).
R=gsathya@chromium.org
Review-Url: https://codereview.chromium.org/2260183003
Cr-Commit-Position: refs/heads/master@{#38763}
Currently when redefining eval or arguments in non-simple parameter list and
destructuring binding, V8 doesn't throw any error, this patch fixes it.
BUG=v8:5201
LOG=N
Review-Url: https://codereview.chromium.org/2185223002
Cr-Commit-Position: refs/heads/master@{#38762}
This is only needed to set a flag on the SharedFunctionInfo generated for a function literal. Hence we only need it in 1 scope, and only read it once. Recursing in that case will be more efficient than always tracking it.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2261693002
Cr-Commit-Position: refs/heads/master@{#38761}
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change.
Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2251433002
Cr-Commit-Position: refs/heads/master@{#38760}
While they have not been observed to slow down real-world use cases,
some blink_layout microbenchmarks feel better with these methods
disabled. In order to be concervative at the launch time, lift
the CFI defense for these methods.
8/10 of these methods will become much faster when an optimization
proposed in https://crbug.com/638056 -- we only need to load vptr
once (before the loop) and have a single CFI check instead of
a check per iteration.
BUG=638056,634139
Review-Url: https://codereview.chromium.org/2258003002
Cr-Commit-Position: refs/heads/master@{#38759}
This isn't the most elegant fix, but I'd prefer to not rework the logic
right now. What happens is:
- Most parts of the Scanner use nullptr to mean, no literal buffer.
- The bookmarking logic may end up with a state where there's a non-nullptr
literal buffer, but it's empty. (length 0)
- These are functionally equivalent, so there's no 'real' bug.
- But it makes it hard to reason. This patch hence checks for length-0
literal buffers, and uses nullptr instead.
R=marja@chromium.org
BUG=chromium:639191 v8:4947
Review-Url: https://codereview.chromium.org/2258073003
Cr-Commit-Position: refs/heads/master@{#38756}
Version 0 dense arrays cannot be deserialized by current Chromium, which
suggests that this is not necessary.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2256413002
Cr-Commit-Position: refs/heads/master@{#38754}
Implement Neg_d and Neg_s in macro-assembler.
Floating point negate instructions are removed in release 6.
On r2, these instructoin do not change the sign of NaN operands.
TEST=cctest/test-run-wasm/RunWasmCompiled_Float32Neg, cctest/test-run-wasm/RunWasmCompiled_Float64Neg
BUG=
Review-Url: https://codereview.chromium.org/2256963003
Cr-Commit-Position: refs/heads/master@{#38749}
This fixes the self-healing mechanism for closures in the interpreter
entry trampoline not that bytecode can be preserved even when baseline
code is already available.
R=rmcilroy@chromium.org
TEST=cctest/test-compiler/IgnitionEntryTrampolineSelfHealing
BUG=chromium:638225
Review-Url: https://codereview.chromium.org/2257143002
Cr-Commit-Position: refs/heads/master@{#38747}
Unify the representation selection rules for NumberAdd/Subtract and
SpeculativeNumberAdd/Subtract wrt. Int32Add/Sub selection. We can
safely use Int32Add/Sub as long as the inputs are in the safe additive
integer range and the output is either truncated to Word32 or provably
in Signed32 or Unsigned32 range.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2253293005
Cr-Commit-Position: refs/heads/master@{#38746}
Changes the control flow builder classes to make use of the
BytecodeLabels helper class.
BUG=v8:4280
LOG=n
Review-Url: https://codereview.chromium.org/2254493002
Cr-Commit-Position: refs/heads/master@{#38744}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control.
Fixing it:
- Don't include stuff in headers unless necessary.
- Include the stuff you need, not some other stuff that happens to include the
stuff you need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2260483002
Cr-Commit-Position: refs/heads/master@{#38740}
Reason for revert:
Tanks octane
Original issue's description:
> [heap] Improve size profiling for ArrayBuffer tracking
>
> Eagerly account for retained sizes during ArrayBuffer tracking. Following up on this,
> we can now do Scavenges if the amount of memory retained from new space is too large.
>
> BUG=chromium:621829
> R=jochen@chromium.org,hpayer@chromium.org
>
> Committed: https://crrev.com/28e13bd6a75c9467dae43043e7b741a1387d5252
> Cr-Commit-Position: refs/heads/master@{#38731}
TBR=jochen@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621829
Review-Url: https://codereview.chromium.org/2261513003
Cr-Commit-Position: refs/heads/master@{#38739}
This patch refactors the traits objects, used by the parser and the
preparser, so that they contain the same set of methods, with the same
signatures.
R=adamk@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2179423002
Cr-Commit-Position: refs/heads/master@{#38736}
Rolling v8/build to d158ac9f154829bb0a57c2fd398972482cebef28
Rolling v8/tools/clang to eebeb555075fbd7bb86829d37f1f7b7d6f10c8e3
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2261613002
Cr-Commit-Position: refs/heads/master@{#38734}
The current "dense" format is not expressive enough to distinguish between
an element that is not defined and one that has the value "undefined",
but in this CL the existing behaviour of Blink is used for such cases.
Format changes to fix these issues could be made later on.
Not included in this CL is compatibility with version 0 arrays.
Those will be implemented in a separate CL.
BUG=chromium:148757
Committed: https://crrev.com/2e000127df2e88e31d352ef70af397741d1f2298
Review-Url: https://codereview.chromium.org/2259633002
Cr-Original-Commit-Position: refs/heads/master@{#38729}
Cr-Commit-Position: refs/heads/master@{#38732}
Eagerly account for retained sizes during ArrayBuffer tracking. Following up on this,
we can now do Scavenges if the amount of memory retained from new space is too large.
BUG=chromium:621829
R=jochen@chromium.org,hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2210263002
Cr-Commit-Position: refs/heads/master@{#38731}
Reason for revert:
Broke MIPS compile due to an uninitialization warning:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/3110/steps/compile/logs/stdio
Original issue's description:
> Blink-compatible serialization of arrays, both dense and sparse.
>
> The current "dense" format is not expressive enough to distinguish between
> an element that is not defined and one that has the value "undefined",
> but in this CL the existing behaviour of Blink is used for such cases.
> Format changes to fix these issues could be made later on.
>
> Not included in this CL is compatibility with version 0 arrays.
> Those will be implemented in a separate CL.
>
> BUG=chromium:148757
>
> Committed: https://crrev.com/2e000127df2e88e31d352ef70af397741d1f2298
> Cr-Commit-Position: refs/heads/master@{#38729}
TBR=jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2255313002
Cr-Commit-Position: refs/heads/master@{#38730}
