The least significant bit of the input value may affect the result of
the conversion through rounding. We OR the least significant with the
second least significant bit to preserve it over the SHR instruction.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1435203003
Cr-Commit-Position: refs/heads/master@{#31969}
Because the Scope will be optimized away by the call to
FinalizeBlockScope in the case where there are no lexical
declarations in the block, this should have no effect on
anything downstream from the Parser, and simply removes
duplicate parsing code.
Due to the change from ParseStatement to ParseStatementListItem,
this will result in slightly different error messages for
lexical declarations in sloppy mode (until those are shipped).
R=littledan@chromium.org, rossberg@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1433743005
Cr-Commit-Position: refs/heads/master@{#31966}
Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object.
R=machenbach@chromium.org,jkummerow@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/1435643002
Cr-Commit-Position: refs/heads/master@{#31964}
This CL fixes several sources of non-predictability by making Platform::MonotonicallyIncreasingTime() the only bottleneck for all time-querying functions and providing PredictablePlatform implementation.
Review URL: https://codereview.chromium.org/1415383004
Cr-Commit-Position: refs/heads/master@{#31959}
This adds initial support for fast inline allocations of JSObject
instances. It currently has exactly the same limitations as Crankshaft.
R=mstarzinger@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1441573004
Cr-Commit-Position: refs/heads/master@{#31957}
This passes both, the actual constructor and the original constructor,
to nodes having the {JSCreate} operator. This is required for allocating
properly subclassed implicit receiver objects.
R=verwaest@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1434873004
Cr-Commit-Position: refs/heads/master@{#31955}
This implements a first version of support for constructor call inlining
in the inlining machinery. For now we can only inline calls where the
actual constructor and the original constructor coincide (i.e. no super
constructor calls). Note that the target of a super constructor call is
loaded with a runtime call, so there is no way for it to be constant
promoted at the moment.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1435873002
Cr-Commit-Position: refs/heads/master@{#31954}
With subclassing and @@toStringTag, %_ClassOf is not necessarily what
you want for ES6 anymore, so better avoid relying on %_ClassOf in our
builtins.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1439003002
Cr-Commit-Position: refs/heads/master@{#31953}
Presently the inline allocation step is a static value defined to be the minimum
of the step sizes over all the observers. The step occur every (approx.) step
byte. This is unfair to observers whose steps are not evenly divisible by the
min step size. For example, consider two observers with steps sizes of 512 and
576 bytes. Across 16kb allocated, you would expect the first observer to be hit
approximately 32 times, and the second observer to be hit approximately 28
times.
In reality, the observers get notified 30 and 15 times respectively. The reason
is that each step is 512 bytes, and since 576 is not evenly divisible by 512,
it gets notified much less frequently.
This CL fixes the problem by making the next step size be the minimum (over all
observers) of the remaining bytes to get to the step, making the steps fair.
BUG=
R=hpayer@chromium.org,ulan@chromium.org
Review URL: https://codereview.chromium.org/1427973006
Cr-Commit-Position: refs/heads/master@{#31948}
Extend the element access specialization to also allow non-JSArray fast
packed elements, which now includes unaliased sloppy and strict
arguments.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1433193003
Cr-Commit-Position: refs/heads/master@{#31943}
Change sloppy and strict arguments objects to FAST_ELEMENTS for their
backing stores, which will allow us to optimize them easier. Also fixes
a bug in the elements accessors that was triggered by this change.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1433133003
Cr-Commit-Position: refs/heads/master@{#31942}
Support lowering of Function.prototype.call in the JSBuiltinReducer,
which is actually straightforward because of the way we represent JS
calls in TurboFan. Currently we cannot inline the actual target yet,
since inlining still runs before typed lowering, but that will be
possible as well soon(ish).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1439533002
Cr-Commit-Position: refs/heads/master@{#31938}
port 1e2770123b (r31914)
original commit message:
Avoid write barriers when storing values in the root set, and use
cheaper write barriers for storing maps or tagged pointers. Also
improve the generated code for write barriers, utilizing the out
of line code mechanism that is available to TurboFan backends,
which moves the unlikely case out of the hot path.
BUG=
Review URL: https://codereview.chromium.org/1435743003
Cr-Commit-Position: refs/heads/master@{#31935}
Changing this value is not guaranteed to work yet, but it needs to be
an arg in order to experiment with it.
Review URL: https://codereview.chromium.org/1427343003
Cr-Commit-Position: refs/heads/master@{#31932}
Popcnt is implemented as an optional operator, which is only implementd by x64
at the moment.
Review URL: https://codereview.chromium.org/1424173006
Cr-Commit-Position: refs/heads/master@{#31928}
