On MIPS arch, all memory accesses (including halfword)
must be aligned to their native size or an alignment exception occurs.
The kernel will fix this up, but with performance penalty.
TEST=test-bytecode-generator/CallRuntime
BUG=
Review URL: https://codereview.chromium.org/1423373004
Cr-Commit-Position: refs/heads/master@{#31845}
Since enabling destructuring already implies enabling default parameters,
there's not a good way to separate these two. Luckily, they're both
feature-complete (save for destructuring assignment).
This causes us to pass an additional 24 test262 tests.
BUG=v8:811, v8:2160
LOG=y
Review URL: https://codereview.chromium.org/1407393009
Cr-Commit-Position: refs/heads/master@{#31844}
The previous code had a mix of breaks, early returns, and switch/case/if
with fallthrough. Now the pattern is to either return for known errors
or break to the bottom of the switch for unhandled tokens.
Also cleaned up random other stuff in the function: removed unnecessary
local vars, shortened position-fetching calls.
Review URL: https://codereview.chromium.org/1412313009
Cr-Commit-Position: refs/heads/master@{#31843}
This patch adds UseCounters for the various language modes. This may
be useful for helping us to prioritize future optimization and
language design decisions.
R=adamk
CC=seththompson
BUG=none
Review URL: https://codereview.chromium.org/1429173002
Cr-Commit-Position: refs/heads/master@{#31841}
Reason for revert:
Causes GC-Stress failures.
Original issue's description:
> [heap] Separate out optimized code map processing.
>
> This separates the post-processing step for optimized code maps out of
> the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
> visit all candidates instead of gathering candidates during marking.
>
> Gathering candidates during marking no longer makes sense, now that the
> majority of SharedFunctionInfo objects will hold such an optimized code
> map. Also it reduces complexity of the implementation. Also conflating
> this mechanism with "code flushing" was confusing.
>
> This reverts commit b6644e8491.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/bb7a5eb2d89bae25f2b5ecb9515669f0ac73c111
> Cr-Commit-Position: refs/heads/master@{#31836}
TBR=ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1412063012
Cr-Commit-Position: refs/heads/master@{#31837}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
This reverts commit b6644e8491.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1421903012
Cr-Commit-Position: refs/heads/master@{#31836}
The new GN rule will enable removal of code which copies natives_blob.bin and
snapshot_blob.bin in Android GN code (for instance "copy_content_shell_assets").
BUG=547162
LOG=Y
Review URL: https://codereview.chromium.org/1412333005
Cr-Commit-Position: refs/heads/master@{#31835}
We are creating a lot of tags. The result is that git 'packs'
some of them. Our parsers in the release script cannot handle
this.
R=machenbach@chromium.org
LONG=N
NOTRY=true
Review URL: https://codereview.chromium.org/1403293009
Cr-Commit-Position: refs/heads/master@{#31833}
Reason for revert:
Breaks build: https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/3565
Original issue's description:
> [heap] Separate out optimized code map processing.
>
> This separates the post-processing step for optimized code maps out of
> the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
> visit all candidates instead of gathering candidates during marking.
>
> Gathering candidates during marking no longer makes sense, now that the
> majority of SharedFunctionInfo objects will hold such an optimized code
> map. Also it reduces complexity of the implementation. Also conflating
> this mechanism with "code flushing" was confusing.
>
> R=ulan@chromium.org
>
> Committed: https://crrev.com/8ad6168d197dd167235c9d342ec7ce37b0daa88b
> Cr-Commit-Position: refs/heads/master@{#31830}
TBR=ulan@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1434503003
Cr-Commit-Position: refs/heads/master@{#31832}
Port ab84025977
Also:
- Fix big-endian compiler hints BYTE_OFFSET macro.
- Clean up PPC code access to compiler hints -- which required some new
SharedFunctionInfo fields to encapsulate kCompilerHintsSmiTagSize.
Original commit message:
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
R=bmeurer@chromium.org, cbruni@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1423713014
Cr-Commit-Position: refs/heads/master@{#31831}
This separates the post-processing step for optimized code maps out of
the CodeFlusher. It uses the complete SharedFunctionInfo::Iterator to
visit all candidates instead of gathering candidates during marking.
Gathering candidates during marking no longer makes sense, now that the
majority of SharedFunctionInfo objects will hold such an optimized code
map. Also it reduces complexity of the implementation. Also conflating
this mechanism with "code flushing" was confusing.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/1426953006
Cr-Commit-Position: refs/heads/master@{#31830}
This inserts a new bit set type Function, which is used to represent
JSFunctions, and uses that type in typed lowering to optimize calls
to use the CallFunction builtin directly. Also allows for better typing
of the typeof operator, which can infern "function" for JSFunctions
properly.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1410343016
Cr-Commit-Position: refs/heads/master@{#31827}
This fixes receiver conversion since the Call builtin does it correctly.
BUG=v8:4526
LOG=n
Review URL: https://codereview.chromium.org/1407373007
Cr-Commit-Position: refs/heads/master@{#31823}
The %_CallFunction doesn't implement the call sequence properly, it
doesn't do the receiver wrapping, nor does it check for
classConstructor. Also the eager deoptimization for %_CallFunction was
seriously b0rked (we must have been lucky with TurboFan so far).
R=yangguo@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1419813010
Cr-Commit-Position: refs/heads/master@{#31821}
TurboFan didn't fully support the relevant ES6 type conversion
intrinsics like %_ToNumber, %_ToLength, %_ToName, %_ToString and
%_ToInteger until now, we always went to the runtime instead. These
intrinsics are now well supported in TurboFan, and we are even able to
generate quite decent code in some cases.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1428243003
Cr-Commit-Position: refs/heads/master@{#31820}
Fix an earlier regression which forbid non-VariableProxy LHS from being
used in for-of loops. Like for-in loops, the spec allows any LHS to be used,
with the sole exception that ObjectLiterals and ArrayLiterals must be valid
AssignmentPatterns.
Also fixes a bug in TurboFan which resulted in incorrectly replacing a variable load with a constant value in some instances, due to the AstLoopAssignmentAnalyzer failing to record the assignment to ForOfStatement's value.
BUG=v8:4418, v8:2720
LOG=N
R=wingo@igalia.com, littledan@chromium.org, adamk@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1411873004
Cr-Commit-Position: refs/heads/master@{#31816}
port ab84025977 (r31790).
original commit message:
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
BUG=
Review URL: https://codereview.chromium.org/1419793007
Cr-Commit-Position: refs/heads/master@{#31815}
Expose the steps for incremental marking and idle scavenge more directly in
NewSpace. Adjust the NewSpace and Heap interfaces to allow callers to be more
clear about how they are interacting with inline allocation steps. This refactor
prepares the ground for more consumers of inline allocation steps (e.g. sampling
heap profiler.)
R=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1404523002
Cr-Commit-Position: refs/heads/master@{#31814}
This CL is a fix for https://codereview.chromium.org/1411223010. (X87: fix
the deoptimization issue.).
ArchDeoptimize instruction may contains duplicated x87 double register as input
parameters. So the scope check is not correct.
BUG=
Review URL: https://codereview.chromium.org/1415023007
Cr-Commit-Position: refs/heads/master@{#31812}
This patch moves ES2015 ToLength semantics on array operations, etc
to from staging to shipping.
R=adamk
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1433473003
Cr-Commit-Position: refs/heads/master@{#31810}
The maximum indexed element size is maxUint32-1, not maxUint32, because
the maximum length of elements is maxUint32. This patch tweaks the limit
to switch to named properties as appropriate.
BUG=v8:4516
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1431503002
Cr-Commit-Position: refs/heads/master@{#31809}
The CL https://codereview.chromium.org/1409013004 added / changed some test cases.
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result
check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function, those inlined
functions has different behavior comparing with GCC ia32 build and x87 build. The major
difference is sse float register still has single precision rounding semantic. While X87
register has no such rounding precsion semantic when directly use register value. The V8
turbofan JITTed has exactly same result in both X87 and IA32 port.
So we add the following sentence to do type case to keep the same precision.
float expect = *i * *j; // *i + *j, etc.
For test case "RunFloat64MulAndFloat64Add1 / RunFloat64MulAndFloat64Add2 / RunFloat64MulAndFloat64Sub1
/ RunFloat64MulAndFloat64Sub2", the expected result calcaulated by GCC has difference precsion
when comparing with V8 turbofan result for X87 platform. (Turbofan X87 result is the same as
IA32 GCC and IA32 Turbofan). So we have to disable those four cases for X87 port.
BUG=
Review URL: https://codereview.chromium.org/1430943002
Cr-Commit-Position: refs/heads/master@{#31808}
This deprecates the ability of the raw machine assembler to utilize the
CallFunctionStub in preparation of the stub itself being deprecated. We
only used this to test instruction selection of calls to stubs that can
deoptimize, the test has been adapted.
R=verwaest@chromium.org
TEST=unittests/InstructionSelectorTest
Review URL: https://codereview.chromium.org/1408193006
Cr-Commit-Position: refs/heads/master@{#31799}
Reason for revert:
MSAN errors on arm64: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/5123/
Original issue's description:
> [es6] Implement destructuring binding in try/catch
>
> The approach is to desugar
>
> try { ... }
> catch ({x, y}) { ... }
>
> into
>
> try { ... }
> catch (.catch) {
> let x = .catch.x;
> let y = .catch.y;
> ...
> }
>
> using the PatternRewriter's normal facilities. This has the side benefit
> of throwing the appropriate variable conflict errors for declarations
> made inside the catch block.
>
> No change is made to non-destructured cases, which will hopefully save
> us some work if https://github.com/tc39/ecma262/issues/150 is adopted
> in the spec.
>
> There's one big problem with this patch, which is a lack of PreParser
> support for the redeclaration errors. But it seems we're already lacking
> good PreParser support for such errors, so I'm not sure that should
> block this moving forward.
>
> BUG=v8:811
> LOG=y
>
> Committed: https://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba
> Cr-Commit-Position: refs/heads/master@{#31797}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811
Review URL: https://codereview.chromium.org/1408063013
Cr-Commit-Position: refs/heads/master@{#31798}
The approach is to desugar
try { ... }
catch ({x, y}) { ... }
into
try { ... }
catch (.catch) {
let x = .catch.x;
let y = .catch.y;
...
}
using the PatternRewriter's normal facilities. This has the side benefit
of throwing the appropriate variable conflict errors for declarations
made inside the catch block.
No change is made to non-destructured cases, which will hopefully save
us some work if https://github.com/tc39/ecma262/issues/150 is adopted
in the spec.
There's one big problem with this patch, which is a lack of PreParser
support for the redeclaration errors. But it seems we're already lacking
good PreParser support for such errors, so I'm not sure that should
block this moving forward.
BUG=v8:811
LOG=y
Review URL: https://codereview.chromium.org/1417483014
Cr-Commit-Position: refs/heads/master@{#31797}
