available. We use this to ensure that snapshots on MacOSX can
use SSE2 instructions. Also clean up and assertify the
handling of things we can't do when we are generating a
snapshot. Fix a bug in the new serialization tests where
they activated Snapshot::enable() too late after code had been
generated that assumed no snapshots.
Review URL: http://codereview.chromium.org/391051
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
regular expressions to be consistent with typeof in other contexts.
Typeof regular expressions should now be 'function' in all contexts.
In the JS natives, IS_FUNCTION, IS_OBJECT, and IS_REGEXP return the
same answers as before.
Review URL: http://codereview.chromium.org/360053
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3231 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the generated code for function.apply there was a loop checking the stack limit for interruption. This loop would call into the runtime system to handle interuption and keep running until there was no interruption. However if the interuption was debug break the runtime system would never clear the interruption as debug break is prevented in builtins are prevented and the assumption here was that returning with the debug break flag set would move execution forward.
Renamed initial_jslimit and initial_climit to real_jslimit and real_climit. Renamed a few external references related to the stack limit as well.
Exposed the real stack limit to generated code to make the stack check when entering function.apply use the real stack limit and not the stack limit which is changed to signal interruption.
Added the real stack limit to the roots array.
BUG=http://code.google.com/p/v8/issues/detail?id=493
TEST=cctest/test-debug/DebugBreakFunctionApply
Review URL: http://codereview.chromium.org/345048
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3229 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
separate JS stack.
In exception handling, we need to be able to compare addresses into
the JavaScript portion of the stack with the address of a C++ handler
on the stack. Since the stacks are separate on the simulator, we need
a JavaScript stack address corresponding to a C++ try catch handler in
order to perform valid address comparisons.
On the simulator, we now link the C++ try catch handlers indirectly
through the JS stack and use the JS stack indirection address for
comparisons.
JS C++
handler
[C++ address] <------ next_
\
\
\----> handler
[C++ address] <------ next_
On actual hardware the C++ try catch handlers continue to be directly
linked.
BUG=http://code.google.com/p/v8/issues/detail?id=271
Review URL: http://codereview.chromium.org/360004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3228 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
There were two separate implementations of the function
'BuildBoilerplate' that is used to compile function declarations and
function literals. The implementations did not do exactly the same
thing. In particular, one ignored the flag --lazy.
Combine the two implementations.
Review URL: http://codereview.chromium.org/360011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3218 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
used to signal that an expression was the immediate subexpression of
typeof, or (?) in the arm of a conditional expression itself in the
typeof state.
It was inconsistently consulted. It was not used for property loads,
but only for slot loads. This means that we matched the Webkit JSC
(not Spidermonkey) behavior for:
typeof(true ? x : y) // throws ReferenceError
and we matched the SpiderMonkey behavior (not JSC) for:
with ({}) { typeof(true ? x : y) } // ==> "undefined"
Now we are expected to match the JSC behavior in all cases.
Review URL: http://codereview.chromium.org/362004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3212 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
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
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
Slots appear only indirectly in the AST (through variables linked to
variable proxies). Slots are shared among variable references, so
putting compilation-time state on them is potentially a source of
bugs. Avoid it for now.
Review URL: http://codereview.chromium.org/284009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3079 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
fast-mode code generator.
AST expression nodes are annotated with a location when doing the
initial syntactic check of the AST. In the current implementation,
expression locations are 'temporary' (ie, allocated to the stack) or
'nowhere' (ie, the expression's value is not needed though it must be
evaluated for side effects).
For the assignment '.result = true' on IA32, we had before (with the
true value already on top of the stack):
32 mov eax,[esp]
35 mov [ebp+0xf4],eax
38 pop eax
Now:
32 pop [ebp+0xf4]
======== On x64, before:
37 movq rax,[rsp]
41 movq [rbp-0x18],rax
45 pop rax
Now:
37 pop [rbp-0x18]
======== On ARM, before (with the true value in register ip):
36 str ip, [sp, #-4]!
40 ldr ip, [sp, #+0]
44 str ip, [fp, #-12]
48 add sp, sp, #4
Now:
36 str ip, [fp, #-12]
Review URL: http://codereview.chromium.org/267118
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
fast code generator is optimized for compilation time and code size.
Currently it is only implemented on IA32. It is potentially triggered
for any code in the global scope (including code eval'd in the global
scope). It performs a syntactic check and chooses to compile in fast
mode if the AST contains only supported constructs and matches some
other constraints.
Initially supported constructs are
* ExpressionStatement,
* ReturnStatement,
* VariableProxy (variable references) to parameters and
stack-allocated locals,
* Assignment with lhs a parameter or stack-allocated local, and
* Literal
This allows compilation of literals at the top level and not much
else.
All intermediate values are allocated to temporaries and the stack is
used for all temporaries. The extra memory traffic is a known issue.
The code generated for 'true' is:
0 push ebp
1 mov ebp,esp
3 push esi
4 push edi
5 push 0xf5cca135 ;; object: 0xf5cca135 <undefined>
10 cmp esp,[0x8277efc]
16 jnc 27 (0xf5cbbb1b)
22 call 0xf5cac960 ;; code: STUB, StackCheck, minor: 0
27 push 0xf5cca161 ;; object: 0xf5cca161 <true>
32 mov eax,[esp]
35 mov [ebp+0xf4],eax
38 pop eax
39 mov eax,[ebp+0xf4]
42 mov esp,ebp ;; js return
44 pop ebp
45 ret 0x4
48 mov eax,0xf5cca135 ;; object: 0xf5cca135 <undefined>
53 mov esp,ebp ;; js return
55 pop ebp
56 ret 0x4
Review URL: http://codereview.chromium.org/273050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
while, and for loops.
Previously they were distinguished by a type field, which required
runtime asserts to avoid invalid nodes (since not all loop types have
the same internal structure). Now they C++ type system is used to
require well-formed loop ASTs.
Because they do not share compilation code, we had very large
functions in the code generators that merely did a runtime dispatch to
a specific implementation based on the type.
Review URL: http://codereview.chromium.org/269049
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3048 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The calls to GenericBinaryStub can now pass the arguments in registers instead of on the stack. It is supported for ADD, SUB, MUL and DIV. The convention in GenericBinaryStub is not changed so the left operand is passed in edx and the right one in eax. When the stub contains smi code arguments are always passed on the stack as the smi code has to have left and right operands on eax and ebx, so moving from edx,eax to eax,ebx is not worth it and the smi code also trashes the registers so if arguments where passed in registers they would have to be saved on the stack anyway.
Added flags to disable the use of certain Intel CPU features to make it easier to test different code paths.
Review URL: http://codereview.chromium.org/246075
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3041 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Named a constant and added an assert to get notified when related constants
change.
Removed reloading of the Array function when Array is called as a constructor as
the Array function is preserved in edi.
This - unlike r2908 and r2909 - both compiles and passes the tests.
Review URL: http://codereview.chromium.org/209012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2940 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The construction of arrays when using the the Array function either as a constructor or a normal function is now handled fully in generated code in most cases. Only when Array is called with one argument which is either negative or abowe JSObject::kInitialMaxFastElementArray (which is currently 1000) or if the allocated object cannot fit in the room left in new space is the runtime system entered.
Two new native code built-in functions are added one for normal invocation and one for the construct call. The existing C++ builtin is renamed, but kept. When the normal invocation cannot be handled in generated code the C++ builtin is called. When the construct invocation cannot be handled in native code the generic construct stub is called (which will end up in the C++ builtin through a construct trampoline).
One thing that might be changed is preserving esi (constructor function) during the handling of a construct call. We know precisily what function we where calling anyway and can just reload it. This could remove the parameter construct_call to ArrayNativeCode and remove the handling of this from that function.
The X64 and ARM implementations are not part of this changelist.
Review URL: http://codereview.chromium.org/193125
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The SCons build now has the options profilingsupport and debuggersupport for controlling the setting of the defines ENABLE_LOGGIGN_AND_PROFILING and ENABLE_DEBUGGER_SUPPORT. By default both are set to true.
The changes to the XCode project have not been tested.
Review URL: http://codereview.chromium.org/195061
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2875 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Use the code patcher for the patching of the JS return sequence used by the debugger.
Added explicit instruction cache flushing in a code patching section which did not have it for completeness, even though it is not required on Intel processors.
Review URL: http://codereview.chromium.org/203016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2870 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Got rid of the debug break on return entry code which did not add anything. It just jumped directly to the debug break on return code.
Removed the CodePatcher class on x64 as it was not implemented.
Added instruction cache flush to where the return sequence was patched on x64.
Added some missing ENABLE_DEBUGGER_SUPPORT #ifdef/#endif.
Review URL: http://codereview.chromium.org/193057
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2863 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Objects which require an additional fixed array to be allocated now have this allocated in generated code as well. Added allocation flags to the macro assembler new space allocation routines.
Changed the ia32 and x64 macro assemblers to take allocation flags to the allocation routines instead of boolean flag.
Review URL: http://codereview.chromium.org/201015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Factored out the allocation in new space from assembler code into the macro assembler. To support the current allocation patterns a number of different functions where required.
This is change is identical to http://codereview.chromium.org/174524 (committed in r2768 and reverted in r2769) except that line 710 in macro-assembler-ia32.cc is
cmp(result_end, Operand::StaticVariable(new_space_allocation_limit));
instead of
cmp(result, Operand::StaticVariable(new_space_allocation_limit));
and pre-submit fixes as well.
TBR=ager@chromium.org
Review URL: http://codereview.chromium.org/174600
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2771 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a
specialized constructor stub is now generated. This generated code allocates the
object and fills in the initial properties directly. If this fails for some
reason code continues in the generic constructor stub which in turn might pass
control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change.
For x64 and ARM the generic construct stub is used.
This is change is identical to http://codereview.chromium.org/174392 (committed in r2753 and reverted in r2754) except that a few parts have already been committed from http://codereview.chromium.org/173469 (committed in r2762).
Review URL: http://codereview.chromium.org/173470
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For objects which only have simple assignments of the form this.x = ...; a specialized constructor stub is now generated. This generated code allocates the object and fills in the initial properties directly. If this fails for some reason code continues in the generic constructor stub which in turn might pass control to the runtime system.
Added counter to see how many objects are constructed using a specialized stub.
The specialized stub is only implemented for ia32 architecture in this change. For x64 and ARM the generic construct stub is used.
Review URL: http://codereview.chromium.org/174392
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During parsing functions are analyzed for statements of the form this.x = ...;. These assignments are categorized in two types: simple and non simple. The simple ones are where the right hand side is known to be either a constant or an argument to the function. If a function only contains statements of this type the property names are collected and for the simple assignments the index of the argument or the constant value assigned are stored as well.
When the initial map for a function is created and the function consists of only this type of assignemnts the initial map is created with a descriptor array describing these properties which will be known to always exist in an object created from the function.
The information on this property assignments is not collected during pre-parsing so if compiling using pre-parse data these optimization hints are not available.
Next step will be to use the information collected for the simple assignments to generate constructor code which will create and initialize the object from this information without calling the code for the function.
Review URL: http://codereview.chromium.org/172088
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2710 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
snapshot creation in a better way.
Encode whether or not the stub should use sse3 instructions in the
minor key of the stub. The stubs generated during snapshot creation
will have sse3 disabled, but they will not be found when sse3 is
enabled. Therefore they will only affect the code generated as part
of the snapshot.
Review URL: http://codereview.chromium.org/172086
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2705 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
fast-mode compiler.
1. We avoid generating a useless temporary for assignments with
nontrivial right-hand sides. Instead of translating id = expr into:
...
tmp = <last expr instruction>
id = tmp
we generate directly
...
id = <last expr instruction>
by passing a data destination ('hint') down the AST. The semantics is
to use the destination as a result location if a temp is needed. It
may be ignored. NULL indicates I don't care and you should generate a
temp.
2. We correctly handle assignments as subexpressions. When building
the CFG for an expression we accumulate the assigned variables and we
emit a move to a fresh temporary if a value in a variable is in
jeopardy of being overwritten.
Review URL: http://codereview.chromium.org/165056
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2643 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
generated in one-pass from the source AST, code is generated from the
CFG. Enabled by the flag --multipass and disabled by default.
Rudimentary and currently only supports literal expressions and return
statements. There are some other known limitations (e.g., missing
support for tracing).
Review URL: http://codereview.chromium.org/159695
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
does not use stack-allocated character as a one-element character
array.
The use at this site was actually safe (Ecma262Canonicalize will only
write to the first character of the array), but not obviously so.
BUG=17103
Review URL: http://codereview.chromium.org/159071
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove the check for deleted properties in the global load inline cache if the property is known to be read only.
Propegate the in loop flag for the global call inline cache.
Changed the propagation of the code flags in the call stub compiler to compute these the same way for all types of call stubs and assert that the flags for the generated code is the same as those used for the cache lookup.
Addressed a few comments from previous review in test-api.cc.
Review URL: http://codereview.chromium.org/150101
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2308 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Fix incorrect signedness in disassembly of umull/mull on ARM.
* Fix incorrect register order in disassembly of umull/mull.
* Fix incorrect assembly of umull on ARM.
* Remove retroactively obsoleted restriction on choice of
registers in mul instructions on ARM.
Review URL: http://codereview.chromium.org/150002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2292 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Marsaglia's multiply-with-carry instead of mixing the
bits obtained from calling the system random() twice.
This seems to be a bit faster and gives a better
distribution than the system random() in particular on
Windows.
Review URL: http://codereview.chromium.org/126113
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2159 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Identify heap numbers that contain non-Smi int32s and do bit
ops on them without calling the fp hardware or emulation.
* Identify results that are non-Smi int32s and write them into
heap numbers without calling the fp hardware or emulation.
* Do unary minus on heap numbers without going into the runtime
system.
* On add, sub and mul if we have both Smi and heapnumber inputs
to the same operation then convert the Smi to a double and do
the op without going into runtime system. This also applies
if we have two Smi inputs but the result is not Smi.
Review URL: http://codereview.chromium.org/119241
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2131 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a trivial per-row compression:
- short aliases are introduced for events and code creation tags;
- in tick events, offsets are used instead of absolute addresses;
- removed 'code-allocation' event, as it seems not used.
The first two options are depend on the new flag: 'compress-log', which is off by default.
On benchmarks run w/o snapshot, this gives 45% log size reduction.
Review URL: http://codereview.chromium.org/119304
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
interceptors and dont-delete attributes.
Minor change to the behavior of eval: throw exception when calling
eval in a context for which the global has been detached. This
matches the behavior of both Firefox and Safari post navigation in the
browser.
Review URL: http://codereview.chromium.org/118374
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
deferred code snippets are highly stylized. They always make a call
to a stub or the runtime and then return. This change takes advantage
of that.
Creating a deferred code object now captures a snapshot of the
registers in the virtual frame. The registers are automatically saved
on entry to the deferred code and restored on exit.
The clients of deferred code must ensure that there is no change to
the registers in the virtual frame (eg, by allocating which can cause
spilling) or to the stack pointer. That is currently the case.
As a separate change, I will add either code to verify this constraint
or else code to forbid any frame effect.
The deferred code itself does not use the virtual frame or register
allocator (or even the code generator). It is raw macro assembler
code.
Review URL: http://codereview.chromium.org/118226
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
submitted in revisions 2093, 2094, 2099, and 2106.
There's no evidence that supports that these changes
should be the cause of the unexplained performance
regressions on the intl2 and DHTML page cyclers.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.
Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.
Review URL: http://codereview.chromium.org/112082
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Running "system" JavaScript with the debug break flag active leads to slow running code while waiting for the break in non "system" JavaScript (one exception to this it is to try to avoid breaks in the clear mirror cache JavaScript code called when leaving the debugger).
* If this happens while processing RegExp running in native code an infinite loop is created as the stack guard handler for RegExp does not move execution forward
Fixed a GC bug in the interrupt handling for RegExp running in native code.
Added test of debug break while in debug message handler callback and debug break while executing a RegExp.
Review URL: http://codereview.chromium.org/115262
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
called from within a loop or not. In the past we lost the
information if a call site went megamorphic before a lazily
compiled callee was called for the first time. Now we track
that correctly (this is an issue that affects richards).
We still don't manage to track the in-loop state through a
constructor call, since constructor calls use LoadICs instead
of CallICs. This issue affects delta-blue. So in this patch
we assume that lazy compilations that don't happen through a
CallIC happen from inside a loop. I have an idea to fix this
but this patch is big enough already.
With our improved tracking of in-loop state I have switched
off the inlining of in-object loads for code that is not in
a loop. This benefits compile speed. One issue is that
eagerly compiled code now doesn't get the in-object loads
inlined. We need to eagerly compile less code to fix this.
Review URL: http://codereview.chromium.org/115744
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2046 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
encoding the values in one word and by using an indirection table for
handles.
This reduces compilation time by roughly 10% and we should be able to make the slow case equality checking of frame elements faster as well.
Review URL: http://codereview.chromium.org/115347
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1949 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The function that prepares a virtual frame slot for writing (in order
to preserve the copy-on-write semantics of aliased frame elements) can
allocate registers, which may spill one from the frame. If we're
unlucky, the spilled register can be the source register for the frame
element write. In that case, ensure we do the write from memory.
Review URL: http://codereview.chromium.org/115125
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1904 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
NPN_Construct allows a NPObject to be called as a construct. For example, the
test case
var s = new app.Packages.java.lang.Integer(5);
app.Packages.java.lang.Integer is a NPObject, and it implements NPN_Construct.
This fix allows a JSObject created by an API function be called as a construct
if it can be called
as a function. This is done by generating the same code for
var s = new app.Packages.java.lang.Integer(5); as
var s = app.Packages.java.lang.Integer(5);
and the caller handles both case correctly. A more sophiscated fix is to one
extra JSConstructCall
frame and allow CallAsConstructor in Builtin::HandleApiCallAsFunction.
This change itself shouldn't affect the semantic of normal case such as:
var a = {};
var s = new a();
A TypeError exception will be thrown in CALL_NON_FUNCTION (runtime.js).
Another part of fix is in the binding code, V8NPObject, which makes
NPN_InvokeDefault or NPN_Construct
call depending on which function is available.
Review URL: http://codereview.chromium.org/100243
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1837 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
stack pointer to change by more than one in a corner case. If we push
a constant smi larger than 16 bits, we push it via a temporary
register. Allocating the temporary can cause a register to be spilled
from the frame somewhere above the stack pointer.
As a fix, do not use pushes to materialize ranges of elements of size
larger than one.
Review URL: http://codereview.chromium.org/92121
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1785 ce2b1a6d-e550-0410-aec6-3dcde31c8c00