directly-applied function literals that are themselves compiled with
the top-level code generator.
The choice is guarded by a test that the function is anonymous (thus
not expected to be recursive) and not in a loop.
A compilation hint is set in the shared function info and used to make
the choice.
Review URL: http://codereview.chromium.org/341081
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3206 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
context. Test contexts are used for the left subexpressions of
short-circuited boolean operators. The right subexpressions inherit
their expression context from the binary op expression.
Compilation of short-circuited operations in effect and test context
is straightforward:
effect(e0 || e1) =
test(e0, L0, L1)
L1: effect(e1)
L0:
test(e0 || e1, L0, L1) =
test(e0, L0, L2)
L2: test(e1, L0, L1)
Because the value of the first subexpression may be needed as the
value of the whole expression in a value context, we introduce a
hybrid value/test contest (the value is needed if true, but not if
false).
value(e0 || e1) =
value/test(e0, L0, L1)
L1: value(e1)
L0:
The compilation of value/test and test/value (introduced by boolean
AND) is:
value/test(e0 || e1, L0, L1) =
value/test(e0, L0, L2)
L2: value/test(e1, L0, L1)
test/value(e0 || e1, L0, L1) =
test(e0, L0, L2)
L2: test/value(e1, L0, L1)
Boolean AND is the dual. The AST nodes themselves (not their parents)
are responsible for producing the proper result (effect, value, or
control flow) depending on their context.
Review URL: http://codereview.chromium.org/339082
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3187 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
o.x() and o[expr]()
other changes:
- Fix missing relocation info for StoreIC on global object.
- Generate only one common return sequence instead of always appending
"return <undefined>" at the end of each function: The first JS
return-statement will generate the common return sequence. All
other return-statements will generate a unconditional branch to the common
return sequence.
Review URL: http://codereview.chromium.org/340037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3183 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The code for .result = (b.y = 99) where b is a global variable is:
push [esi+0x17]
mov ecx,0xf5c229ad ;; object: 0xf5c229ad <String[1]: b>
call LoadIC_Initialize
nop
mov [esp],eax
mov eax,0xc6
mov ecx,0xf5c25c41 ;; object: 0xf5c25c41 <String[1]: y>
call StoreIC_Initialize
nop
mov [esp],eax
pop [ebp+0xf4]
There is still some room for improvement in the generated code.
Other changes:
- Replaced switch-statement in FastCodeGenerator::VisitProperty with DropAndMove(...)
- Do not emit nop after IC calls on ARM.
Review URL: http://codereview.chromium.org/347001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
context of the expressions they label. Introduce an "unintialized"
location to catch failure to assign any location at all.
Changed the object literal initialization on ARM to use a Store IC in
the same cases where it did on the other platforms. This was required
because the location of the literal property name is given an
"unitialized" location.
Review URL: http://codereview.chromium.org/339045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3171 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
location to an Expression AST node from the node's parent to the node
itself.
This allows an inherited code generation context from a parent node to
be passed arbitrarily far down the tree (eg, the subexpression of a
unary not is in the same context as the unary expression itself, the
then and else subexpressions of the ternary operator are in the same
context as the whole expression, and so forth).
We do not yet take advantage of this in the backend (eg, the right
subexpression of short-circuited OR is still compiled by using the
parent's destination location, rather than the subexpression's
itself).
Review URL: http://codereview.chromium.org/340005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3163 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- don't engage the processing thread of CPU profiling until the first time profiling is resumed, this saves us a thread allocation for the majority of users;
- don't log shared libraries addresses: this is useless for JS-only profiling, and also consumes time on startup.
Review URL: http://codereview.chromium.org/340013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3154 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
String slices from RegExp replace results is now encoded in either one or two smis. Substrings are not used any more.
If the existing one smi encoding cannot hold the start/length information two smis are used the first having the negative length and the second having the start.
This is in preparation for removing string slices.
Review URL: http://codereview.chromium.org/342015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3153 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Literals now have a location of temporary by default and are
responsible for moving themselves into their location like all other
expressions.
The constant location turned out not to allow us to avoid checking
subexpressions in AST interior nodes, and it turned out to require
checking after some normal calls to Visit (like for the arguments to a
call). With this change do not have to check after a call to Visit
that we got our result in the expected location.
Review URL: http://codereview.chromium.org/339004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3137 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When using xor to zero a 64-bit register, generate 32-bit instruction instead.
(according to Intel 64-bit mode coding guidelines)
previous code for zeroing RAX:
xor rax, rax
==>
new code for zeroing RAX:
xor eax, eax
The 32-bit operand form has the same semantics: It also zeroes the upper
32-bit of rax and its encoding uses 1 byte less.
Review URL: http://codereview.chromium.org/330018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of individual changes:
- Added infrastructure for custom stub caching.
- Push the code object onto the stack in exit calls instead of a
debug/non-debug marker.
- Remove the DEBUG_EXIT frame type.
- Add a new exit stub generator for API getters.
Review URL: http://codereview.chromium.org/330017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3130 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I also added more unit tests for literals.
Right now, the fast compiler produces code very similar to
the existing code generator. We may consider different ways to
further compact the generated code for top-level code.
ARM always goes through a runtime function to initialize computed
properties in an object literal whereas IA32 and x64 use StoreIC.
Review URL: http://codereview.chromium.org/316009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3129 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As the list of code-stubs is used in two places it is now handled through a macro to keep this in sync. As some code-stubs is only used on ARM the list have been split into two parts to indicate this and get rid of dummy implementation on ia32 and x64 platforms.
BUG=484
Review URL: http://codereview.chromium.org/335025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3127 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Inline assembly is not available in Visual C++ 64-bit version so use RtlCaptureContext to capture execution context. RtlCaptureContext is not available on Windows 2000 so this change removes Windows 2000 support. If this turns up causing trouble we can revert to only use RtlCaptureContext in 64-bit and inline assembly in 32-bit.
Review URL: http://codereview.chromium.org/335008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in a non-test (ie, value or effect) context. (It is implicitly not in
a test context because the code generator does not support expressions
in a test context yet.)
Compilation is essentially the same as in the optimized code
generator. The expression (e0 || e1) is compiled as if it were
(let (temp = e0) temp ? temp : e1).
On ia32 and x64 a single shared ToBoolean stub is used to convert a
value to a flag. The inlined checks assumed by the stub are reordered
to compare to undefined (the common case in toplevel code?) first. On
ARM a call to the runtime is used. In the interest of code size no
checks are yet inlined on ARM.
Review URL: http://codereview.chromium.org/334006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. This is a follow-on CL to
http://codereview.chromium.org/293023 .
Based on review feedback, defined the behavior of storing NaN and
+/-Infinity into external arrays of integer types as storing 0. Added
test cases. Added fucomi instruction to assembler. Fixed bug in
KeyedLoadIC::GenerateExternalArray when allocation of HeapNumber
failed. Fixed bug in encoding of 16-bit immediate arithmetic
instructions in 64-bit port.
Removed raising of exceptions for negative array indices passed to
external arrays and associated tests. Based on current discussion in
WebGL working group, will probably end up removing the exception
throwing altogether.
Review URL: http://codereview.chromium.org/294022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
currently compiled the same as with the optimizing compiler: they are
cloned from a boilerplate object and the boilerplate objects are
lazily constructed.
Also changed argument pushing on ARM to use stm (store multiple),
which required changing the order of arguments to the runtime
functions DeclareGlobals and NewClosure. They were only used from
generated code.
Finally, changed the toplevel code generator so that stack pops to
discard a temporary became addition to the stack pointer on ia32 and
x64.
Review URL: http://codereview.chromium.org/303021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3110 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For .result = /abc.*/g we generate the following IA-32 code:
...
mov ebx,[edi+0x17]
mov eax,[ebx+0xb]
cmp eax, 0xf5d0e135 ;; object: 0xf5d0e135 <undefined>
jnz done
push ebx
push 0x2
push 0xf5d13805 ;; object: 0xf5d13805 <String[5]: abc.*>
push 0xf5d13815 ;; object: 0xf5d13815 <String[1]: g>
call RuntimeStub_MaterializeRegExpLiteral
done:
push eax
pop [ebp+0xf4]
...
This is very similar to the code previously generated except we do not
generate deferred code for the case where we call the runtime.
On ARM we use the stm instruction to make pushing the arguments more compact.
Review URL: http://codereview.chromium.org/300037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
when using snapshots.
The alignment of new space has to match the alignment in the snapshot,
but the max committed amount of memory does not.
For now, we assume that the default semispace size is always used in a
snapshot.
Review URL: http://codereview.chromium.org/300036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. The optimizations are patterned after
those previously done for CanvasPixelArray. This CL adds all of the
necessary framework but continues to use the generic KeyedLoadIC and
KeyedStoreIC code, to create a baseline for benchmarking purposes. The
next CL will add the optimized ICs to ic-ia32.cc and ic-x64.cc.
These new CanvasArray types have different semantics than
CanvasPixelArray; out-of-range values are clamped via C cast
semantics, which is cheaper than the clamping behavior specified by
CanvasPixelArray. Out-of-range indices raise exceptions instead of
being silently ignored.
As part of this work, pulled FloatingPointHelper::AllocateHeapNumber
up to MacroAssembler on ia32 and x64 platforms. Slightly refactored
KeyedLoadIC and KeyedStoreIC. Fixed encoding for fistp_d on x64 and
added a few more instructions that are needed for the new ICs. The
test cases in test-api.cc have been verified by hand to exercise all
of the generated code paths in the forthcoming specialized ICs.
Review URL: http://codereview.chromium.org/293023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
constant known at compile time. Do not ever use the stack to
materialize (non-function-argument) constants. Currently, constants
are only the non-materialized, non-function literals in the AST.
It is a known issue that there is no test coverage for the cases of
assigning a non-literal to a variable and returning a literal. Those
code paths are unreachable and tests will be added when they become
reachable.
For the code '.result = true', we had previously on ia32:
27 push 0xf5c28161 ;; object: 0xf5c28161 <true>
32 pop [ebp+0xf4]
Now:
27 mov eax,0xf5c26161 ;; object: 0xf5c26161 <true>
32 mov [ebp+0xf4],eax
======== We had previously on x64:
25 movq r10,0x7fb8c2f78199 ;; object: 0x7fb8c2f78199 <true>
35 push r10
37 pop [rbp-0x18]
Now:
25 movq r10,0x7fb131386199 ;; object: 0x7fb131386199 <true>
35 movq [rbp-0x18],r10
The generated code for ARM did not include the extra memory traffic.
It was already eliminated by the ARM assembler's push/pop elimination.
Review URL: http://codereview.chromium.org/300003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3088 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
