The majority of context slot accesses are to the local context (current context
register and depth 0), so this adds bytecodes to optimise for that case.
This cuts down bytecode size by roughly 1% (measured on Octane and Top25).
Review-Url: https://codereview.chromium.org/2459513002
Cr-Commit-Position: refs/heads/master@{#40641}
This flag is on by default for now. Whenever heuristics in the compiler
pipeline decide to use Ignition+TurboFan, then {BytecodeGraphBuilder} is
active. Removing the flag reduces maintenance overhead.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2437103002
Cr-Commit-Position: refs/heads/master@{#40639}
This CL adds simple implementation of break and stepping-related functionality
as required by the debug-step.js test. This includes
* stepOver, stepInto, stepOut
* setBreakPoint
* clearBreakPoint
* evaluate
Some of these, e.g. setBreakPoint are not fully implemented for all cases but
only for the ones we need right now.
One interesting result of this is that using the inspector protocol is roughly
14x slower for debug-step.js (14s instead of 0.5s). One cause of this seems to
be iteration over all object properties in toProtocolValue, which is used to
serialize JS objects before being sent over the wire (e.g. FrameMirrors). This
is something that should be fixed at some point. In the meantime, the test now
runs 100 instead of 1000 iterations.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2447073007
Cr-Commit-Position: refs/heads/master@{#40636}
This adds a wrapper class around the inspector protocol for use in
debugger tests. The interface is intended to stay similar to the
currently exposed DebuggerContext.
Right now, we support adding a listener, (partial) handling of the
AfterCompile event, and enabling/disabling the debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2451153003
Cr-Commit-Position: refs/heads/master@{#40635}
In the asm.js to wasm pipeline, we generate an entry function with
BUILTIN code, but still attached to a TYPE_NORMAL script.
This fix avoids trying to set a breakpoint there, resulting in a crash
on DCHECK(shared->HasDebugInfo()).
Also add two inspector tests to track regressions.
BUG=v8:5568
R=titzer@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2457433002
Cr-Commit-Position: refs/heads/master@{#40633}
The reasons are:
1) Type feedback vectors are not shared between different native contexts and
therefore the IC handler created for one native context will not be reused
in other native context.
2) Access rights revocation is not supported at all, therefore given (1) once
we pass the access check we don't have to check access rights again.
BUG=v8:5561
Review-Url: https://codereview.chromium.org/2455953002
Cr-Commit-Position: refs/heads/master@{#40627}
The assumptions that OSR code is installed on {JSFunction} objects no
longer holds with TurboFan and hence {assertOptimized} can report a
different result dependeing on how OSR code is treated. This is working
as intended.
R=mythria@chromium.org
Review-Url: https://codereview.chromium.org/2453313002
Cr-Commit-Position: refs/heads/master@{#40624}
This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2443573002
Cr-Commit-Position: refs/heads/master@{#40617}
We used to point elsewhere, for instance the right-hand-side of an assignment.
Small limitation: Since variable proxies only have a start position, not an end
position, the best we can do is point at the first character. (We cannot rely
on the scanner's last token position because Declare may be called long after
the variable has been scanned.)
R=adamk@chromium.org
BUG=v8:5572
Review-Url: https://codereview.chromium.org/2447143005
Cr-Commit-Position: refs/heads/master@{#40613}
This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.
I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.
Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}
Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).
The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.
Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):
List type Zone memory used Time taken
-----------------------------------------------------------------------
Zone array (for comparison) 131072 B
Ideally initialized ZoneList 131088 B 0.062ms
ChunkZoneList 134744 B 0.052ms <--new thing
ZoneDeque 141744 B
ZoneLinkedList 393264 B
Initially empty ZoneList 524168 B 0.171ms <--right now
ChunkZoneList only push_front 524320 B
Review-Url: https://codereview.chromium.org/2449383002
Cr-Commit-Position: refs/heads/master@{#40602}
- Modifies RegisterConfiguration to specify complex aliasing on ARM 32.
- Modifies RegisterAllocator to consider aliasing.
- Modifies ParallelMove::PrepareInsertAfter to handle aliasing.
- Modifies GapResolver to split wider register moves when interference
with smaller moves is detected.
- Modifies MoveOptimizer to handle aliasing.
- Adds ARM 32 macro-assembler pseudo move instructions to handle cases where
split moves don't correspond to actual s-registers.
- Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of
different widths, and moves involving pseudo-s-registers.
- Adds unit tests for FP operand interference checking and PrepareInsertAfter.
- Adds more tests of FP for the move optimizer and register allocator.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2410673002
Cr-Commit-Position: refs/heads/master@{#40597}
For instance, when an import cannot be resolved, actually
point at the corresponding import statement.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2451153002
Cr-Commit-Position: refs/heads/master@{#40594}
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@{#40592}
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}
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}
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}
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}
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}
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}
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}
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}
