This removes special casing for the 'f.arguments' property accessor. Any
local 'arguments' variable should not be allowed to influence the value
returned by the indirect 'f.arguments' property. That property creates a
new object with a separate identity everytime it is read. This is by now
consistent with other browsers.
R=rossberg@chromium.org
TEST=mjsunit/arguments-indirect
Review URL: https://codereview.chromium.org/1408983006
Cr-Commit-Position: refs/heads/master@{#31776}
Adds support for calling JS runtime functions. Also changes the bytecode
array builder to allow calling functions with an invalid argument
register if the call takes no arguments.
Adds the bytecode CallJSRuntime.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1410003003
Cr-Commit-Position: refs/heads/master@{#31774}
Use the type specified for StoreField and StoreElement to check whether
we are storing a TaggedSigned value, and skip the write barrier for the
write completely in that case. Also make sure to set that field type
appropriately for JSGlobalObjectSpecialization.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1410743009
Cr-Commit-Position: refs/heads/master@{#31772}
We don't need to distinguish between signed and unsigned integral
representations in the big boy type system. It actually even hurts
in some cases. The representation is only about the way the values
are mapped to bits in memory/registers, but the interpretation of
the bits is specified by the semantic dimension.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1416953006
Cr-Commit-Position: refs/heads/master@{#31771}
We used to mark a block as needing frame based solely on
the spill list. With splintering, that is not entirely
accurate. With this change, for ranges that spill only in
deferred blocks, we mark the start of each block in which a
child range spills as needing a frame.
BUG=v8:4533
LOG=n
Review URL: https://codereview.chromium.org/1408183007
Cr-Commit-Position: refs/heads/master@{#31769}
The "harmony"-prefixed files have been included in the snapshot for
several releases now, and were only separate originally to enable
loading them via a runtime flag. This patch simply merges them into
the main implementation files for Arrays and TypedArrays, respectively.
Review URL: https://codereview.chromium.org/1416243007
Cr-Commit-Position: refs/heads/master@{#31767}
Corrects LdaGlobal to deal with TypeofMode::INSIDE_TYPEOF so that it
doesn't throw a reference error on undefined globals.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1422443006
Cr-Commit-Position: refs/heads/master@{#31757}
Original issue's description:
> [es6] Fix Function and GeneratorFunction built-ins subclassing.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/99e7f872d3d0a5fb799dcbafb05537cda491314a
> Cr-Commit-Position: refs/heads/master@{#31708}
The problem was in another CL, this is a clean reland with improved tests.
BUG=v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1415683007
Cr-Commit-Position: refs/heads/master@{#31756}
This matches the approach used for @@isConcatSpreadable, and seems to
match what Mozilla is planning to do in Firefox.
Given that there's already little compatibility around cross-origin toString
results, there seems to be little hazard in making this change even before
spec language hits the HTML spec.
BUG=v8:3502, v8:4289, chromium:532469
LOG=n
Review URL: https://codereview.chromium.org/1432543002
Cr-Commit-Position: refs/heads/master@{#31755}
If the property is a data property on the holder (or does not exist) and is a readonly data property in the receiver, then we must fail.
R=rossberg, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1424233005
Cr-Commit-Position: refs/heads/master@{#31751}
The JSNativeContextSpecialization class is getting rather huge with all
the stuff related to property and element access going in. Splitting off
the global object related stuff into JSGlobalObjectSpecialization seems
like a natural separation, especially since the global object
specialization is sort of separate issue anyway. This is neutral
functionality- and performance-wise.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1417043006
Cr-Commit-Position: refs/heads/master@{#31748}
1) The Map::CopyInitialMap() did not set descriptor's array if
the source initial map had one.
2) Subclasses are temporarily disallowed to have more in-object
properties than the parent class (for GC reasons).
BUG=v8:3101, v8:3330, v8:4531
LOG=N
Review URL: https://codereview.chromium.org/1431593003
Cr-Commit-Position: refs/heads/master@{#31743}
This changes the inlining candidates to be stored in a sorted set of
unique entries instead of a vector. We can avoid the final sorting
operation by amortizing the cost across insertions and also duplicate
entries are not created in the first place. Duplicate entries cause
crashes when candidates are processed.
R=bmeurer@chromium.org
BUG=chromium:549113
LOG=n
Review URL: https://codereview.chromium.org/1430553003
Cr-Commit-Position: refs/heads/master@{#31742}
Existing code was assuming that 'lexical' blocks were the same as basic
blocks, therefore code which emitted jumps within a lexical block (e.g.,
logical or) would in some occassions incorrectly omit a necessary
ToBoolean.
This change removes Enter/LeaveBlock from BytecodeArrayBuilder and
instead tracks basic blocks via label bindings and jump operations. The
change also ensures we don't emit dead code at the end of a basic block,
and adds tests of the edge cases.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1406983010
Cr-Commit-Position: refs/heads/master@{#31741}
The flake detection is done on the infra-side according to
the contents of the json test results. We don't want the
runner to fail after flakes.
This was controlled on the infra side by accepting any exit
codes so far. After the swarming switch, this is more
difficult, because the runner is wrapped by the swarming
collect script. There, failing exit codes can mean many
things, including network failures. Therefore, we now
force exit code 0 with test failures if those failures
are reported in the formal test results json.
The infrastructure will take care of reporting the flakes
and failures accordingly.
BUG=chromium:535160
LOG=n
Review URL: https://codereview.chromium.org/1416373005
Cr-Commit-Position: refs/heads/master@{#31740}
TurboFan is actually able to generate property access to all prototypes
of all primitives, except the special Oddball primitives that have no
wrapper counterparts (namely null and undefined from the ES6 point of
view).
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1409163007
Cr-Commit-Position: refs/heads/master@{#31739}
This CL fixes an invalid cast in Slow_ArrayConcat (a Proxy on a DICTIONARY_ELEMENTS array's prototype chain).
It also adds some comments and minor drive-by refactorings to other PrototypeIterator use sites.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1402393003
Cr-Commit-Position: refs/heads/master@{#31738}
Reason for revert:
This CL reintroduces all kinds of funny moves for Merges of deferred code, which makes jump threading ineffective.
Original issue's description:
> [turbofan] Remove redundant code.
>
> When I centralized the treatment of memory operands, I forgot to delete
> the old code.
>
> There is a semantic difference between the old and new code. The old
> code was handling either memory operands, or ranges that had a spilled
> predecessor. The new code handles just memory operands. It may
> happen that (using LinearScan) an active range is spilled when trying
> to allocate another range (see SplitAndSpillIntersecting). That may make
> it a candidate for the old version of the code, however, since we would
> have spilled up to a register use, the old code wouldn't have had taken
> effect.
>
> Perf data shows this nuance doesn't make a difference in perf.
>
> BUG=
>
> Committed: https://crrev.com/c03d7a7f03657a452f71277d84e435ed73566327
> Cr-Commit-Position: refs/heads/master@{#31729}
TBR=jarin@chromium.org,mtrofin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1416293004
Cr-Commit-Position: refs/heads/master@{#31732}
Implement the missing bits for named access to Number values, which is
basically always done on the Number prototype. Crankshaft only deals
with Number primitives in the polymorphic case, while we generally
support Numbers even for monomorphic access.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1425293004
Cr-Commit-Position: refs/heads/master@{#31731}
When I centralized the treatment of memory operands, I forgot to delete
the old code.
There is a semantic difference between the old and new code. The old
code was handling either memory operands, or ranges that had a spilled
predecessor. The new code handles just memory operands. It may
happen that (using LinearScan) an active range is spilled when trying
to allocate another range (see SplitAndSpillIntersecting). That may make
it a candidate for the old version of the code, however, since we would
have spilled up to a register use, the old code wouldn't have had taken
effect.
Perf data shows this nuance doesn't make a difference in perf.
BUG=
Review URL: https://codereview.chromium.org/1428943004
Cr-Commit-Position: refs/heads/master@{#31729}
