This changes all direct function calls in Crankshaft to pass undefined
via the register expected to hold the new.target value. Note that the
register is still ignored by all callees for now.
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/1459183002
Cr-Commit-Position: refs/heads/master@{#32125}
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 CL should be reverted after investigating the size chrasher.
BUG=chromium:556912
LOG=n
Review URL: https://codereview.chromium.org/1455273003
Cr-Commit-Position: refs/heads/master@{#32119}
Since {CancelAndWait} blocks on the tasks that are still present in the internal
hashmap, we are not allowed to remove the task upon trying to cancel it using
{TryAbort}.
The previous implementation suffered from a bug where:
1) The task was created and handed over to the platform.
2) The task was started by the platform, setting it to running state.
3) We called {TryAbort}, effectively removing it from the manager, but failing
to cancel (as it was already running)
4) All tasks finished running, indicating this with their own semaphore.
5) The platform was stuck (scheduling) before destroying the task.
6) Main thread finished its work, waiting for all the necessary tasks, and the
isolate terminated.
7) The platform destroyed the task, calling the destructor, calling into an
already freed isolate.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1460763004
Cr-Commit-Position: refs/heads/master@{#32118}
This changes the interface descriptor for the arguments adaptor to also
contain an explicit register for the new.target value. Note that the
stub still clobbers the register for now.
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/1457313002
Cr-Commit-Position: refs/heads/master@{#32117}
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}
A64 loads and stores can have much larger positive than negative
immediate offsets, and since most frame slots are below fp, we can
significantly improve accesses by basing them on sp instead. Typical
example:
Before After
mov x16, #-416
str x20, [fp, x16] str x20, [jssp, #32]
Notable benchmark results include lua_binarytrees, which improves by
about 7.5% on A57 and 5% on A53. Several other asm.js benchmarks gain
2-4%.
Review URL: https://codereview.chromium.org/1376173003
Cr-Commit-Position: refs/heads/master@{#32111}
This CL introduces a concept of UseInfo (but internally it still
uses machine types). The idea of UseInfo is to separate the concept
of truncation (what information is actually used by the user node)
and the concept of preferred representation. At the moment, the
truncation is (clumsily) represented by the type part of the
underlying machine type (UseInfo::type_).
Moreover, in this CL, we never specify the signedness of the use
because use signedness does not really make sense:
- if we care about the sign, it should be in the input's type
(this is DCHECKed).
- if we do not care (e.g., trunctaing word32), then it should not
be necessary. (And it is upto the user how it interprets the bits.)
Review URL: https://codereview.chromium.org/1462503005
Cr-Commit-Position: refs/heads/master@{#32110}
Port 1389b9f53c
Port dffecf31fc
Implementation of two optional turbofan operators Float64RoundUp and
Float64RoundTiesEven on MIPS32. On MIPS32R2 with FP64 and MIPS32R6 with FP64
we can support these two operators directly using MIPS instructions. This
code implements these two operators. Also, added some DCHECKs for instructions
which are supported on MIPS32R2 with FP64 and MIPS32R6 with FP64 to detect
wrong usage on unsupported architectures.
BUG=
Review URL: https://codereview.chromium.org/1448383002
Cr-Commit-Position: refs/heads/master@{#32108}
If the shared function info is newly compiled when looking for
it in the script (Debug::FindSharedFunctionInfoInScript), then
we can bypass iterating the heap to find JSFunctions referencing
it (Debug::PrepareFunctionForBreakpoints).
BUG=v8:4553
LOG=N
Review URL: https://codereview.chromium.org/1454673002
Cr-Commit-Position: refs/heads/master@{#32107}
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}
Rolling v8/build/gyp to e1133480da78cd4a23a8cec604d1d6d46dab35d6
Rolling v8/buildtools to 818123dac34899ec230840936fc15b8b2b5556f9
Rolling v8/tools/clang to 650a79a0bd9b486fa688d8a71ce00674e9e2c096
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1456323002
Cr-Commit-Position: refs/heads/master@{#32100}
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}
Replaces the UnboundedQueue (SP/SC) with LockedQueue (MP/MC). This is necessary
as we can have multiple tasks (on multiple platform threads) reporting code move
events.
Note that the sampling queue is not affected by this change.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1457483002
Cr-Commit-Position: refs/heads/master@{#32086}
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 triggers TurboFan whenever functions containing spread expressions
of any kind are marked for optimization. Note that this increases the
set of functions being eligible for optimization.
R=rossberg@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1461603002
Cr-Commit-Position: refs/heads/master@{#32083}
This makes sure we are using the right signedness - either the input
specifies signedness or the use must declare it does not care.
This requires some hole-punching in for-in so that the
representation selector understands the smi-ness of index.
Moreover, phi needs to pass the truncation along (maybe
slightly scary).
Review URL: https://codereview.chromium.org/1455123002
Cr-Commit-Position: refs/heads/master@{#32081}
This ensures the class in question specifies the correct equality and
hashing function when instantiated. Note that this introduces two new
structs (i.e. OpEqualTo and OpHash) which can be used for defaults
within OpParameter as well.
R=titzer@chromium.org,bmeurer@chromium.org
TEST=cctest/test-operator
Review URL: https://codereview.chromium.org/1455913003
Cr-Commit-Position: refs/heads/master@{#32080}
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}
Retrieve the native context/global object from the Node being
specialized in the JSNativeContextSpecialization and the
JSGlobalObjectSpecialization classes. For this we introduce two
new methods NodeProperties::GetSpecializationNativeContext and
NodeProperties::GetSpecializationGlobalObject, which walk up
the context chain and might in the end take the native context
from the outermost activation (if native context specialization
is enabled). This allows us to run the native context specialization
pass as part of the inlining phase without hacking some of that into
the JSInliner.
Also refactor the NodeProperties::GetSpecializationContext method
that was previously local to the JSContextSpecialization.
Also refactor two other oddities in JSNativeContextSpecialization.
R=jarin@chromium.org
BUG=v8:4470, v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1451143005
Cr-Commit-Position: refs/heads/master@{#32076}
