This simplifies the layout of dependent code array and optimizes it for sparse dependency groups.
BUG=chromium:554488
LOG=NO
Review URL: https://codereview.chromium.org/1435313002
Cr-Commit-Position: refs/heads/master@{#32170}
We should not be counting the bump pointer allocations done during scavenge as
the objects are copied. The inline allocation observers were getting unnecessary
notifications.
R=hpayer@chromium.org, ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1465633002
Cr-Commit-Position: refs/heads/master@{#32153}
* Adds a PrepareForTailCall instruction that bumps the stack in the case that
the number of parameters passed to the callee causes the stack to exceed the
calleer's frame size.
* Uses the gap resolver to move the saved caller return address and frame
pointer to the approprate location in the tail-called frame.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1455833004
Cr-Commit-Position: refs/heads/master@{#32151}
This change introduces register re-mapping to avoid assignment hazards
in binary expressions. Expressions that cause problems typically have
the form y = x + (x = 4);. The problem occurs because the lhs value
evaluates to the register holding x. The rhs updates that register and
then applying the operation would use the new value as the lhs.
By tracking loads and stores in binary expressions the generator is now
able to detect when condition occurs and uses a temporary register for
the rhs value. When the binary expression evaluation is complete the
variable is updated with the latest temporary.
A new bytecode Mov performs this update without touching the
accumulator.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1412683011
Cr-Commit-Position: refs/heads/master@{#32141}
Adds support for the New, CallRuntime and CallJSRuntime bytecodes in
BytecodeGraphBuilder. Also adds BuildLoadObjectField,
BuildLoadGlobalObject and BuildLoadNativeContextField helpers.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456483002
Cr-Commit-Position: refs/heads/master@{#32136}
The TruncateFloat64ToUint64 operator converts a float64 to an uint64 using
round-to-zero rounding mode (truncate). If the input value is outside uint64
range, then the result depends on the architecture. I provide an implementation for x64 and arm64.
@v8-ppc-ports and @v8-mips-ports, can you do the implementations for ppc64 and mips64?
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1457373002
Cr-Commit-Position: refs/heads/master@{#32127}
Following logic is using for getting function name in JSFunction::GetDebugName:
1. if function has displayName and its type is string then use it
2. if function has defined property Function.name as value and its type string then use it
3. otherwise use SharedFunctionInfo::DebugName as functionName.
JSFunction::GetDebugName is exposed in V8 API and in FunctionMirror interface.
BUG=chromium:17356
R=yangguo@chromium.org,mstarzinger@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1449473005
Cr-Commit-Position: refs/heads/master@{#32124}
Fixing failures in cctest/test-assembler-mips/CVT on Mips32R2 without
FP64 support
BUG=
Review URL: https://codereview.chromium.org/1459763003
Cr-Commit-Position: refs/heads/master@{#32121}
This adds an explicit parameter to the call descriptor having kind
kJSCallFunction representing the new.target value. Note that for now
this parameter is not yet passed in and hence cannot be used yet. Also
contains some refactoring of how parameter index value are calculated,
establishing Linkage as the central point for such index computations.
This is a preparatory CL to allows us passing new.target in a register
instead of via a side-channel through the construct stub frame.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1461973002
Cr-Commit-Position: refs/heads/master@{#32112}
The ChangeFloat64ToInt64 operator changes the representation of a
float64 input value to int64 if the input value can be represented
exactly on int64. Otherwise the result is currently undefined.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1455983002
Cr-Commit-Position: refs/heads/master@{#32102}
We currently assume that all prototype maps are stable, which is
not guaranteed for certain keyed access patterns. So we explicitly
disallow optimizing the element access there for now.
BUG=chromium:557807, v8:4470
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1456973004
Cr-Commit-Position: refs/heads/master@{#32101}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
Now that we no longer require AllocationInfo::limit to be aligned [1], we can do
more accurate inline-allocation-observation. This lets us get notified when the
next allocation that crosses the step-size boundary is allocated.
Fixed the test-cases. They make significantly more sense now given the step
sizes and the number of times we get notifications. For example, with a step
size of 512, an allocation of 16kb results in 32 notifications instead of 30
now.
[1] https://codereview.chromium.org/1444883003R=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1448913003
Cr-Commit-Position: refs/heads/master@{#32091}
This fixes undefined behavior with the OpParameter helper in some of our
node matchers. There was a constness mismatch of the template parameter.
R=oth@chromium.org,mythria@chromium.org
Review URL: https://codereview.chromium.org/1453973004
Cr-Commit-Position: refs/heads/master@{#32087}
When adding properties to the result object, that object's prototype chain should be ignored.
Review URL: https://codereview.chromium.org/1458873002
Cr-Commit-Position: refs/heads/master@{#32085}
This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread
Review URL: https://codereview.chromium.org/1455953002
Cr-Commit-Position: refs/heads/master@{#32079}
...based on the 2-lock algorithm by M. Scott and M. Michael (1992).
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1448283004
Cr-Commit-Position: refs/heads/master@{#32078}
If the input type does not help us, we are conservative and truncate (rather than guessing signed).
Review URL: https://codereview.chromium.org/1455103002
Cr-Commit-Position: refs/heads/master@{#32075}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1453733002
Cr-Commit-Position: refs/heads/master@{#32050}
Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.
Landed on behalf of rmcilroy.
TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1449373002
Cr-Commit-Position: refs/heads/master@{#32049}
