This way, many files which only need CompilationInfo but not compiler.h
and its dependencies can include just compilation-info.h.
BUG=
Review-Url: https://codereview.chromium.org/2284313003
Cr-Commit-Position: refs/heads/master@{#39038}
This is the first step towards unifying ParseVariableDeclarations.
BUG=
Review-Url: https://codereview.chromium.org/2297643002
Cr-Commit-Position: refs/heads/master@{#39036}
Rolling v8/build to 679c9fd3fa7390897bcf6891f0dc57a5e5dced0d
Rolling v8/tools/mb to d939c7d364f0565ac2ddcae09aafe01c9bf8007d
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2293333002
Cr-Commit-Position: refs/heads/master@{#39035}
The way we use FinishRegion for transitioning stores makes them eligible
for elimination by TypedOptimization, which is unintended and removes
the atomicity of the transitioning stores. This is a quickfix to ensure
that we don't remove the FinishRegion nodes during TypedOptimization;
the real fix is probably to have separate region operators for value
(producing) regions (i.e. allocations) and for effect-only regions (i.e.
transitioning stores).
R=jarin@chromium.org
BUG=v8:5303
Review-Url: https://codereview.chromium.org/2293023003
Cr-Commit-Position: refs/heads/master@{#39033}
If the type of a tracked field or element value is less precise than the
advertised type of the field or element load, then we replace the load
operation with a TypeGuard that guards the advertised type.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2295643002
Cr-Commit-Position: refs/heads/master@{#39032}
We (mis)used Type::Class to track stable field maps in the past. But
that always more or less unsupport and wrong for various reasons, mostly
because the class types do not really present static information and
thus it is possible to violate fundamental assumptions of the type
system (i.e. intersecting class types and other types produces
"interesting" results).
Now it is possible to finally nuke the class types completely and thus
simplify (and ideally correctify) the type system further.
Note to performance sheriff: We do expect to see some performance
regressions from this change. This is because we do not yet have a sane
replacement mechanism to track known field maps and utilize them during
LoadElimination. This will be accomplished in a follow up CL.
BUG=v8:5270,v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2293343002
Cr-Commit-Position: refs/heads/master@{#39031}
This removes two bits of duplication:
- Parsing of each AssignmentExpression, which previously was called
first outside the loop and then inside the loop.
- Parsing of arrow rest parameters, which previously was handled
separately for the one-arg and N-arg cases.
The only change in behavior is in a few error messages.
Review-Url: https://codereview.chromium.org/2279363002
Cr-Commit-Position: refs/heads/master@{#39030}
Reason for revert:
Fails to reject "{*foo: 1}" as an object literal, found
by the fuzzer:
https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/12315/steps/Fuzz%20on%20Ubuntu-12.04/logs/stdio
Original issue's description:
> Refactor object/class literal property name parsing
>
> This patch arranges that property names are parsed in a single pass,
> reporting the name as well as the type of the property, instead of
> parsing qualifiers like 'static' or 'get' initially as names and then
> re-parsing. This change is easier to reason about, very slightly (4%)
> faster in some cases (although slower in other, less common ones, though
> this slowdown will be fixed in an upcoming patch), and is a prerequisite
> for separating the parsing of object and class literal properties, which
> will become increasingly important as ECMAScript adds more class features.
>
> Committed: https://crrev.com/6dd26c729584024e17a05a2a76b319d4aecdc138
> Cr-Commit-Position: refs/heads/master@{#39027}
TBR=littledan@chromium.org,marja@chromium.org,bakkot@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2295743003
Cr-Commit-Position: refs/heads/master@{#39029}
Test ensuring globals are isolated between instances. Also
added support for globals section to mjsunit's
WebModuleBuilder as a prerequisite.
BUG=
Review-Url: https://codereview.chromium.org/2296993002
Cr-Commit-Position: refs/heads/master@{#39028}
This patch arranges that property names are parsed in a single pass,
reporting the name as well as the type of the property, instead of
parsing qualifiers like 'static' or 'get' initially as names and then
re-parsing. This change is easier to reason about, very slightly (4%)
faster in some cases (although slower in other, less common ones, though
this slowdown will be fixed in an upcoming patch), and is a prerequisite
for separating the parsing of object and class literal properties, which
will become increasingly important as ECMAScript adds more class features.
Review-Url: https://codereview.chromium.org/2278153004
Cr-Commit-Position: refs/heads/master@{#39027}
Increasingly, we avoid using the representation dimension of Type,
and set it explicitly ourselves.
BUG=
Review-Url: https://codereview.chromium.org/2290233002
Cr-Commit-Position: refs/heads/master@{#39026}
When changing from Tagged to Float64 representation, it's not unlikely
to see a HeapNumber (or if feedback says so, an Oddball), so we
shouldn't penalize the code that deals with this case by marking it as
deferred.
R=mvstanton@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2295933003
Cr-Commit-Position: refs/heads/master@{#39025}
When FieldType::None() returns a cast Smi::FromInt(0), which translates
as nullptr, the FieldType::IsNone() check becomes equivalent to
`this == nullptr` which is not allowed by the standard and
therefore optimized away as a false constant by GCC 6.
This has lead to crashes when invoking methods on FieldType::None().
Using a different Smi constant for FieldType::None() makes the compiler
always include a comparison against that value. The choice of these
constants has no effect as they are effectively arbitrary.
BUG=https://github.com/nodejs/node/issues/8310
Review-Url: https://codereview.chromium.org/2292953002
Cr-Commit-Position: refs/heads/master@{#39023}
If the input of grow-memory was not representable as a SMI, then the
input was not passed correctly to the runtime, which caused a crash.
With this CL the input of grow-memory is checked before the runtime is
called.
R=titzer@chromium.org, gdeepti@chromium.org
TEST=mjsunit/wasm/grow-memory.js:testGrowMemoryTrapsWithNonSmiInput()
Review-Url: https://codereview.chromium.org/2288773002
Cr-Commit-Position: refs/heads/master@{#39022}
Now incremental marking tracing outputs isolate and timestamp:
[41894:0x21efec0] 17253 ms: [IncrementalMarking] Start (old space step)
This patch also adds walltime duration of incremental marking to GC trace output.
BUG=
Review-Url: https://codereview.chromium.org/2293883002
Cr-Commit-Position: refs/heads/master@{#39016}
This commit introduces several new types:
* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
WasmStackFrame and returns a pointer to the corresponding type for each
frame.
* The JS callsite object now contains the frame array and frame index
as internal fields.
Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.
BUG=
Review-Url: https://codereview.chromium.org/2275233002
Cr-Commit-Position: refs/heads/master@{#39015}
With this CL we use isolate->native_context() to provide a context for
the CEntryStub of the runtime call. The native_context() is sufficient
here because Runtime::kWasmThrowTypeError does not use the context.
R=titzer@chromium.org
TEST=mjsunit/wasm/ffi-error.js
BUG=chromium:639492
Review-Url: https://codereview.chromium.org/2291043002
Cr-Commit-Position: refs/heads/master@{#39014}
Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8
Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f
Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5
Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Committed: https://crrev.com/3b8a2e5129fec64674bb0191cba5aa4592d08d5f
Review-Url: https://codereview.chromium.org/2289063002
Cr-Original-Commit-Position: refs/heads/master@{#38995}
Cr-Commit-Position: refs/heads/master@{#39010}
For arch variants loongson and r1 neg instruction does not change the
sign for NaN-like operands, the same as r2 neg. This fix adjusts macro
assembler Neg_s and Neg_d arch variant logic so the correct code would
be generated for loongson and r1.
BUG=
Review-Url: https://codereview.chromium.org/2287333002
Cr-Commit-Position: refs/heads/master@{#39007}
Put the types for the Date builtins into the TypeCache, and add
support for Date.prototype.getDay and Date.prototype.getMinutes.
R=epertoso@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2296593002
Cr-Commit-Position: refs/heads/master@{#39005}
This replaces the target-selection options (such as "--enable-vfp3")
with a simpler, absolute "--arm-arch" option. This eliminates inferences
and avoids surprising behaviour in impossible situations (such as
"--enable-vfp3 --no-enable-armv7").
The available options are:
--arm-arch=armv6 ARMv6 + VFPv2
--arm-arch=armv7 ARMv7 + VFPv3-D32 + NEON
--arm-arch=armv7+sudiv ARMv7 + VFPv4-D32 + NEON + SUDIV
--arm-arch=armv8 ARMv8 (+ all of the above)
For now, the default setting is "armv8", which results in behaviour very
similar to the existing defaults.
BUG=v8:5077
Review-Url: https://codereview.chromium.org/2223433002
Cr-Commit-Position: refs/heads/master@{#39004}
The comment for the Proxy::New functions seems inaccurate and is
currently identical to Map::New:
3090 /**
3091 * Creates a new empty Map.
3092 */
3093 static Local<Map> New(Isolate* isolate);
This commit updates the comment to describe that it creates a Proxy and
not a Map.
BUG=
Review-Url: https://codereview.chromium.org/2176063002
Cr-Commit-Position: refs/heads/master@{#39002}
This CL is a prequisite for the stack machine changes, which will need
to use temporaries in various places due to the stack height requirements
on blocks.
R=ahaas@chromium.org,bradnelson@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2280063002
Cr-Commit-Position: refs/heads/master@{#39001}
It emits spurious -Wmaybe-uninitialized warnings. Initializing these variables
shouldn't do any harm (with an optimizing compiler), so this seems the quickest
way to mollify gcc.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2290653003
Cr-Commit-Position: refs/heads/master@{#39000}
Otherwise, we'd hold on to the resources until the embedder frees them
which might take a long time
R=marja@chromium.org,verwaest@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2297523002
Cr-Commit-Position: refs/heads/master@{#38999}
Reason for revert:
Breaks tsan build generation:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11441
Original issue's description:
> Update V8 DEPS.
>
> Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8
>
> Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f
>
> Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5
>
> Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3
>
> TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
>
> Committed: https://crrev.com/3b8a2e5129fec64674bb0191cba5aa4592d08d5f
> Cr-Commit-Position: refs/heads/master@{#38995}
TBR=hablich@chromium.org,vogelheim@chromium.org,v8-autoroll@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2290163002
Cr-Commit-Position: refs/heads/master@{#38998}
This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.
This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
instruction.
* Lookup itself is naive in that it just returns the first code object
for which (next_code_obj_addr > pc). It does not check that pc is
actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
but with the wrong code object.
This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.
BUG=v8:5311
Review-Url: https://codereview.chromium.org/2284673002
Cr-Commit-Position: refs/heads/master@{#38996}
Rolling v8/build to 52f474cdb9e67007b938fd4a47220cb3c012e5e8
Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 84d90b2cc3f01a39bf73a8119a5cec0337d00c9f
Rolling v8/tools/clang to 3e1948978834c16073c1b076410df1a80adda1f5
Rolling v8/tools/mb to ac239cc82ef08858d6f2b75216dd13afcdbc6ac3
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2289063002
Cr-Commit-Position: refs/heads/master@{#38995}
port 56429fc146 (r38978)
original commit message:
Introduced MachineType::TaggedSigned() and TaggedPointer().
The idea is to quit using the representational dimension of Type, and
instead encode this information in the MachineRepresentation (itself
lightly wrapped in MachineType, along with MachineSemantic).
There are three parts to the whole change:
1) Places that set the machine representation - constant nodes, loads nad
stores, global object and native context specialization.
2) Places that propagate type/representation - this is representation
inference (aka simplified lowering). At the end of this process we
expect to have a MachineRepresentation for every node. An interesting
part of this is phi merging.
3) Places that examine representation - WriteBarrier elimination does this.
Currently it's looking at the Type representation dimension, but as
a part of this change (or in a soon-to-follow change) it can simply
examine the MachineRepresentation.
BUG=
Review-Url: https://codereview.chromium.org/2293603003
Cr-Commit-Position: refs/heads/master@{#38993}
port 1915762cc8 (r38968)
original commit message:
These JavaScript operators were special hacks to ensure that we always
operate on Smis for the magic for-in index variable, but this never
really worked in the OSR case, because the OsrValue for the index
variable didn't have the proper information (that we have for the
JSForInPrepare in the non-OSR case).
Now that we have loop induction variable analysis and binary operation
hints, we can just use JSLessThan and JSAdd instead with appropriate
Smi hints, which handle the OSR case by inserting Smi checks (that are
always true). Thanks to OSR deconstruction and loop peeling these Smi
checks will be hoisted so they don't hurt the OSR case too much.
Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
we have to lower it to JSLessThan to get the loop induction variable
goodness.
BUG=
Review-Url: https://codereview.chromium.org/2286353003
Cr-Commit-Position: refs/heads/master@{#38992}
This unblocks moving off having to hold on to a compiled module
template.
Once we don't have the template, when we have a single instance, the
instance and wasm module share the same compiled code. We will want
to clear that code off instance-specific stuff, when the instance is
unreferenced and should be GC-ed (stuff like the instance heap, for
instance). However, the deopt data will maintain a strong reference,
blocking the GC: the module object strongly references the compiled
code, which strongly references the instance object through the deopt
data.
This change addresses that by making that last reference weak.
BUG=v8:5316
Review-Url: https://codereview.chromium.org/2284683005
Cr-Commit-Position: refs/heads/master@{#38990}
