Don't use the generic algorithm, but instead start going into the
direction of ControlReducer, using a stack plus a revisit queue to
not miss any more possibilities for reductions anymore.
TEST=cctest,unittests
R=dcarney@chromium.org
Committed: f047507370
Review URL: https://codereview.chromium.org/726513002
Cr-Commit-Position: refs/heads/master@{#25345}
Revert "Fix for an assertion failure in Map::FindTransitionToField(...). Appeared after r25136."
This revert is made in order to revert r25099 which potentially causes renderer hangs.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/722873004
Cr-Commit-Position: refs/heads/master@{#25332}
Don't use the generic algorithm, but instead start going into the
direction of ControlReducer, using a stack plus a revisit queue to
not miss any more possibilities for reductions anymore.
TEST=cctest,unittests
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/726513002
Cr-Commit-Position: refs/heads/master@{#25326}
There's no need to apply the 0x1f mask to right hand sides of shifts if
the input is already in range [0,31].
TEST=cctest,unittests
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/718193003
Cr-Commit-Position: refs/heads/master@{#25313}
Lowering of NumberToUint32 and NumberToInt32 was not correctly accounting for the sign of the input and the sign of the output, emitting the wrong representation changes.
Along the way, I've found cases where MachineOperatorBuilder would break if fed a machine type for loads or stores that was not cached, requiring MachineOperatorBuilder to take zone to allocate operators for these cases.
R=bmeurer@chromium.org, jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/714613002
Cr-Commit-Position: refs/heads/master@{#25247}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.
When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable
Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.
R=adamk@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/705663004
Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The spec explicitly forbids them. V8 never handled them properly either, just
the Scanner accepted them (it had code to add them literally to the
LiteralBuffer) and later on, Regexp constructor disallowed them.
According to the spec, unicode escapes in regexp flags should be an early error
("It is a Syntax Error if IdentifierPart contains a Unicode escape sequence.").
Note that Scanner is still more relaxed about regexp flags than the
spec. Especially, it accepts any identifier parts (not just a small set of
letters) and doesn't check for duplicates.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/700373003
Cr-Commit-Position: refs/heads/master@{#25215}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>;
R=svenpanne@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/682143003
Patch from Weiliang <weiliang.lin@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
