Introducing a virtual-frame-inl.h file containing some platform-independent
virtual frame function which are small enough to be inlined.
Removed unnecessary #include of virtual-frame.h from register-allocator-inl.h
and added the necessary explicit includes in a number of files.
Review URL: http://codereview.chromium.org/660104
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3962 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A list of bailout descriptions is kept in the CompilationInfo
structure that is shared between the primary and secondary code
generators. The primary adds a description to the list for each
bailout position.
Responsibility for binding labels is moved from the primary to the
secondary code generator. All the labels still target the start of the
secondary code and the compilation state of the primary is still
ignored.
Move the compilation mode flag to the CompilationInfo.
Review URL: http://codereview.chromium.org/651031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently we only pass a boolean parameter indicating whether
the input operands to the GenericBinaryOpStub are guaranteed
to be numbers or not.
Instead we pass the complete number type as a parameters. This
allows to use more precise type information for code generation
in the stub.
Also make the computation of the result type more precise and correct on both ia32 and x64.
Review URL: http://codereview.chromium.org/593110
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
NumberToString in runtime JavaScript is inlined through a call to a stub. Currently the stub only checks the number string cache and only if the number is a smi. Code is shared with the inlining of number string cache lookup when adding a smi to a string.
Review URL: http://codereview.chromium.org/604062
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3865 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Each frame element gets a new attribute with number type information. A frame element can be:
- smi
- heap number
- number (i.e. either of the above)
- or something else.
The type information is propagated along with all virtual frame operations.
Results popped from the frame carry the number information with them.
Two optimizations in the code generator make use of the new
information:
- GenericBinaryOpSyub omits map checks if input operands are numbers.
- Boolean conversion for numbers: Emit inline code for converting a number (smi or heap number) to boolean. Do not emit call to ToBoolean stub in this case.
Review URL: http://codereview.chromium.org/545007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3861 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
bailouts. For now the virtual-frame state at entry of a function is
hard-coded when using the virtual-frame based compiler as the
secondary compiler.
Setup frame pointer correctly on function entry on ARM in
fast-codegen-arm.
Review URL: http://codereview.chromium.org/569010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3776 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a preparation step for including number type information
in the virtual frame. We need a common place where we can update
the number type information of the result of a binary operation
since we should not modify the state of the virtual frame elements
directly.
Review URL: http://codereview.chromium.org/551080
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3661 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a function is called with a value type as the receiver this is now boxed as an object.
This is a low-impact solution where the receiver is only boxed when required. For IC calls to the V8 builtins values are not boxed and as most of the functions on String.prototype, Number.prototype and Boolean.prototype are sitting there most IC calls on values will not need any boxing of the receiver.
For calls which are not IC calls but calls through the CallFunctionStub a flag is used to determine whether the receiver might be a value and only when that is the case will the receiver be boxed.
No changtes to Function.call and Function.apply - they already boxed values. According to the ES5 spec the receiver should not be boxed for these functions, but current browsers have not adopted that change yet.
BUG=223
TEST=test/mjsunit/value-wrapper.js
TEST=test/mjsunit/regress/regress-crbug-3184.js
Review URL: http://codereview.chromium.org/542087
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3617 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a stub to allocate and fill a string object with a substring from another string.
Use the rep movs instruction to copy the string data as it turned out to be the fastest way.
While preparing this I experimented with some SSE2 instructions, so the instructions movdqa and movdqu are still in the IA-32 assembler even though they are not used.
Review URL: http://codereview.chromium.org/525085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3554 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Calls to RegExp no longer have to be via a call to the runtime system. A new stub have been added which can handle this call in generated code. The stub checks all the parameters and creates RegExp entry frame in the same way as it is created by the runtime system. Bailout to the runtime system is done whenever an uncommon situation is encountered or when the static data used is not initialized. After running the native RegExp code the last match info is updated like in the runtime system.
Currently only ASCII strings are handled.
Added another argument to the RegExp entry frame. It indicated whether the call is direct from JavaScript code or through the runtime system. This information is used when RegExp execution is interrupted. If an interruption happens when RegExp code is called directly a retry is issued causing the interruption to be handled via the runtime system. The reason for this is that the direct call to RegExp code does not support garbage collection.
Review URL: http://codereview.chromium.org/521028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3542 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds a code stub which can do most of what Heap::AllocateConsString can do. It bails out if the result cannot fit in new space or if the result is a short (flat) string and one argument is an ascii string and the other a two byte string. It also bails out if adding two one character strings as Heap::AllocateConsString has special handling of this utilizing the symbol table. The stub is used both for the binary add operation and for StringAdd calls from runtime JavaScript files. Extended the string add test to cover all sizes of flat result stings.
Review URL: http://codereview.chromium.org/442024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3400 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Summary:
This change fixes a performance regression introduced by the special
handling of regular expressions in typeof expressions.
As a result we regain ~8% speedup on 3d-raytrace and ~13% on boyer
(vs bleeding edge)
Description:
The macros IS_OBJECT and IS_FUNCTION are frequently used in the
JS runtime functions.
By introducing new inlined runtime functions %_IsFunction and %_IsObject
we avoid invoking the more expensive %_ClassOf function plus comparing
its result to a string.
Review URL: http://codereview.chromium.org/399111
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3335 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Condition block of do/while statements is a valid break location so it should have its own position. The block is represented by a regular Expression node so we cannot store the position in it, instead the position is stored in a separate field in DoWhileStatement AST node.
BUG=514
Review URL: http://codereview.chromium.org/385136
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3312 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
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
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
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
