Avoid the hacking in JSIntrinsicLowering and provide a proper simplified
operator ObjectIsReceiver instead that is used to implement %_IsJSReceiver
which is used by our JavaScript builtins and the JSInliner.
R=jarin@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1657863004
Cr-Commit-Position: refs/heads/master@{#33675}
Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
BUG=chromium:579009
LOG=Y
Review URL: https://codereview.chromium.org/1642223003
Cr-Commit-Position: refs/heads/master@{#33674}
(Trying to finish FastAccessorAssembler this week. This should make it easier to pick up the Blink side of this work later on.)
BUG=chromium:508898
SOUNDTRACK=http://youtu.be/i1EG-MKy4so
LOG=Y
Review URL: https://codereview.chromium.org/1620293002
Cr-Commit-Position: refs/heads/master@{#33671}
Also changes SKIP to FAIL to ensure we know when we have fixed a test.
BUG=v8:4280,v8:4680
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm64_dbg,v8_linux_arm_dbg
Review URL: https://codereview.chromium.org/1656803002
Cr-Commit-Position: refs/heads/master@{#33665}
After this change, the functionality of the CodeStubAssembler should be
sufficient to generate non-trivial stubs (e.g. the KeyedLoadIC) with control
flow, variables and probing of internal meta data structures.
Specifically this patch:
* introduces a Label class, which allows stubs to construct graphs that don't
have linear control graphs.
* introduces a Variable class. Variables can be bound to Node* values at
different points in a non-linear control flow graph. In conjunction with the
Label machinery, the CodeStubAssembler ensures that Phi nodes are inserted at
the "minimal" set of merge points.
* adds Tail calling support to other Stubs and to any arbitrary code whose
interface can be described by a CallInterfaceDescriptor.
* provides new macros for accessing FixedArray elements that are optimized for
use with Smi values.
Review URL: https://codereview.chromium.org/1649723002
Cr-Commit-Position: refs/heads/master@{#33664}
There's no point in having %_IsFunction as inline intrinsic, as it
is only used in non performance critical code, which is already full
of runtime calls anyway, so %IsFunction will do the trick as well.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1658123002
Cr-Commit-Position: refs/heads/master@{#33660}
This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.
The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.
The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).
In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.
TBR=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1655833002
Cr-Commit-Position: refs/heads/master@{#33656}
This patch adds a UseCounter for each of the following:
- Allowing duplicate sloppy-mode block-scoped function declarations
in the exact same scope
- for-in loops with an initializer
The patch also refactors some of the declaration code to clean it up and
enable the first counter, and adds additional unit tests to nail down
the semantics of edge cases of sloppy-mode block-scoped function declarations.
BUG=v8:4693,chromium:579395
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1633743003
Cr-Commit-Position: refs/heads/master@{#33650}
The runtime call to Runtime::kReThrow does not need a frame-state node
attached, the frame-state input count is zero. This restructures the
graph builder to not instantiate a FrameStateBeforeAndAfter for it.
R=jarin@chromium.org
TEST=cctest/test-run-bytecode-graph-builder
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1654833002
Cr-Commit-Position: refs/heads/master@{#33641}
Set the bytecode array correctly in Runtime_SetCode.
This fixes issues with building the snapshot with ignition enabled.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1647913002
Cr-Commit-Position: refs/heads/master@{#33638}
Although x87 has 8 registers, it use only 1 double register in TurboFan code generation for some limitations.
So for TestStackSlot() function, use the num_allocatable_double_registers() to check the avaliable double registers
of TurboFan is more suitable than num_double_registers().
BUG=
Review URL: https://codereview.chromium.org/1653913002
Cr-Commit-Position: refs/heads/master@{#33636}
The reachability of a bytecode is implied by a live environment reaching
the bytecode during the abstract control flow simulation of the bytecode
iteration perfromed by the graph builder. There is no need to compute it
upfront anymore.
Also, the upfront computation was only an approximation when it came to
the reachability of an exception handler. This is why several tests for
translation of exception handlers can now be enabled.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1645293003
Cr-Commit-Position: refs/heads/master@{#33634}
The CL #33347 (https://codereview.chromium.org/1589363002) added the RunRoundInt32ToFloat32 test case and X87 failed at it.
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
Here is the key comments from CL #31808
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.
For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
fail.
So we add the following sentence to do type case to keep the same precision for RunRoundInt32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).
BUG=
Review URL: https://codereview.chromium.org/1649323002
Cr-Commit-Position: refs/heads/master@{#33630}
In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.
R=rossberg@chromium.org
BUG=chromium:582051
LOG=N
Review URL: https://codereview.chromium.org/1648263002
Cr-Commit-Position: refs/heads/master@{#33627}
Associate a type with foreign functions at their callsite.
Associate a type with foreign variables.
More pervasively forbid computation in the module body.
Confirm foreign call arguments are exports.
Pass zone to more Type constructors, for consistency.
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=test-asm-validator
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1643003004
Cr-Commit-Position: refs/heads/master@{#33622}
String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:
if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
/* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);
This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.
No observable change in behavior is intended.
Review URL: https://codereview.chromium.org/1612323003
Cr-Commit-Position: refs/heads/master@{#33616}
Previously, String.prototype.normalize constructed its ICU input
string as a null-terminated string. This creates a bug for strings
which contain a null byte, which is allowed in ECMAScript. This
patch constructs the ICU string based on its length so that the
entire string is normalized.
R=jshin@chromium.org
BUG=v8:4654
LOG=Y
Review URL: https://codereview.chromium.org/1645223003
Cr-Commit-Position: refs/heads/master@{#33614}
The for-in slow mode implementation in Crankshaft unconditionally
deoptimizes when %ForInFilter returns undefined instead of just
skipping the item. Even worse, there's nothing we can learn from
that deopt, so we will eventually optimize again and hit exactly
the same problem again once we get back to optimized code.
R=mvstanton@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1647093002
Cr-Commit-Position: refs/heads/master@{#33609}
Reason for revert:
problems on Mac64
Original issue's description:
> [turbofan] Add the StackSlot operator to turbofan.
>
> The StackSlot operator allows to allocate a spill slot on the stack. We
> are going to use this operator to pass floats through pointers to c
> functions, which we need for floating point rounding in the case where
> the architecture does not provide rounding instructions.
>
> R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
>
> Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
> Cr-Commit-Position: refs/heads/master@{#33600}
TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1644283002
Cr-Commit-Position: refs/heads/master@{#33601}
So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.
BUG=v8:3650,v8:4715
LOG=n
Review URL: https://codereview.chromium.org/1650493002
Cr-Commit-Position: refs/heads/master@{#33599}
This is to fix a bug in the bytecode graph builder. This cl adds a new merge
node before we copy the environment on conditional/unconditional jumps. Since
these environments could be merged later, we add a place holder merge so that
the control dependencies are correctly merged. If we do not have a merge node
we may incorrectly merge the dependencies into the previous block.
For ex: test-run-variables/ContextStoreVariables in cctests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1641143002
Cr-Commit-Position: refs/heads/master@{#33591}
avoid jump threading erasing the reconstruction of a frame, if the
frame was elided.
BUG=
Review URL: https://codereview.chromium.org/1642823002
Cr-Commit-Position: refs/heads/master@{#33590}
ES2015 Annex B.1.4 specifies a restricted pattern language for unicode
mode. This change reflects that, based on some test262 test cases.
R=littledan@chromium.org
BUG=v8:2952
LOG=N
Review URL: https://codereview.chromium.org/1645573002
Cr-Commit-Position: refs/heads/master@{#33584}
Reason for revert:
Revert patch due to a number of failures appearing on the MIPS v8 simulator
Original issue's description:
> MIPS: Add FPXX support to MIPS32R2
>
> The JIT code generated by V8 is FPXX compliant
> when v8 compiled with FPXX flag. This allows the code to
> run in both FP=1 and FP=0 mode. It also alows v8 to be used
> as a library by both FP32 and FP64 binaries.
>
> BUG=
>
> Committed: https://crrev.com/95110dde666158a230a823fd50a68558ad772320
> Cr-Commit-Position: refs/heads/master@{#33576}
TBR=paul.lind@imgtec.com,gergely.kis@imgtec.com,akos.palfi@imgtec.com,ilija.pavlovic@imgtec.com,marija.antic@imgtec.com,miran.karic@imgtec.com,balazs.kilvady@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1646813003
Cr-Commit-Position: refs/heads/master@{#33583}
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1641083003
Cr-Commit-Position: refs/heads/master@{#33582}
This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1641723002
Cr-Commit-Position: refs/heads/master@{#33580}
