port b6737c56eaf51d63ab83b6529f657c15f834623c (r25187)
original commit message:
Turn ToNumberStub into a PlatformCodeStub again.
The HydrogenCodeStub is too expensive and there's no easy way to reduce
this cost, so turning it into a PlatformCodeStub solves that problem until
we can use TurboFan for code stubs.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/714573003
Patch from Chunyang Dai <chunyang.dai@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25227}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25227 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
This does the following optimization during ChangeLowering:
ChangeTaggedToFloat64(JSToNumber(x)) =>
if IsSmi(x) then ChangeSmiToFloat64(x)
else let y = JSToNumber(x) in
if IsSmi(y) then ChangeSmiToFloat64(y)
else LoadHeapNumberValue(y)
Also cleanup/rearrange some code duplication in ChangeLowering.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/703103003
Cr-Commit-Position: refs/heads/master@{#25195}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25195 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
The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.
The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.
This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/706533005
Cr-Commit-Position: refs/heads/master@{#25179}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Emscripten requires little-endian arch. It has assertion for endianness:
assert(HEAPU8[0] === 255 && HEAPU8[3] === 0,
'Typed arrays 2 must be run on a little-endian system');
TEST=mjsunit/asm/embenchen/*
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/708663003
Patch from Paul Lind <paul.lind@imgtec.com>.
Cr-Commit-Position: refs/heads/master@{#25177}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25177 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
