Commit Graph

136 Commits

Author SHA1 Message Date
vegorov@chromium.org
3ccc885c78 Revert arguments access support for inlined functions (r11109,r11118).
We are inserting HPushArgument instructions after HEnterInlined based on the environment at the point of the first arguments access. Which might create use before def if there are redundant phis in the environment. 
Review URL: https://chromiumcodereview.appspot.com/9837041

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11128 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-23 15:39:34 +00:00
vegorov@chromium.org
b7dca5d5a7 Support arguments object access from inlined functions.
R=fschneider@chromium.org
TEST=test/mjsunit/compiler/inline-arguments.js

Review URL: https://chromiumcodereview.appspot.com/9837002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-22 13:53:28 +00:00
fschneider@chromium.org
1a29d5cf33 Revert dynamic frame alignment (r9415)
Marking aligned frames with a marker can produce false positives since
an optimized frame spill slot may be mistakenly seen as a marker value.

It also breaks the debugger reproducably: Tested when enabling alignment
for all functions and running the debugger unit tests.

BUG=v8:2009
TEST=no crashes in EarleyBoyer
Review URL: https://chromiumcodereview.appspot.com/9703110

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-19 07:45:06 +00:00
vegorov@chromium.org
da03f56b1f Inline functions that use arguments object in f.apply(o, arguments) pattern.
Support arguments materialization after deoptimization in all frames (not only in topmost one).

R=fschneider@chromium.org

Review URL: https://chromiumcodereview.appspot.com/9643001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11008 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-12 12:49:41 +00:00
ulan@chromium.org
1767fef60b Implement date library functions in C++.
Developed together with Andreas Rossberg based on:
  https://chromiumcodereview.appspot.com/9117034/
  https://chromiumcodereview.appspot.com/9307083/

R=rossberg@chromium.org

Review URL: https://chromiumcodereview.appspot.com/9572008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10983 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-09 12:07:29 +00:00
rossberg@chromium.org
8604da7f06 New class for Date objects: caches individual date components.
First step, cache slots not used yet.

R=ulan@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9117034

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10981 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-09 11:11:55 +00:00
mstarzinger@chromium.org
fd5640cf7a Implement inlined object allocation in Crankshaft.
Generates inlined code for object allocation specific to the initial map
of the given constructor function. Also forces completion of inobject
slack tracking while crankshafting to finalize instance size of these
objects.

R=vegorov@chromium.org
TEST=mjsunit/compiler/alloc-object

Review URL: https://chromiumcodereview.appspot.com/9370019

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10881 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-01 11:10:28 +00:00
fschneider@chromium.org
15542081e9 Pass zone explicitly to zone-allocation on x64 and ARM.
This is a very mechanical change to reduce the number of calls to
Isolate::Current that come with every plain new-allocation.

BUG=v8:1802
Review URL: https://chromiumcodereview.appspot.com/9491004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10857 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-28 10:53:13 +00:00
mstarzinger@chromium.org
170511e52a Fix presubmit errors in previous revision.
R=ulan@chromium.org

Review URL: https://chromiumcodereview.appspot.com/9495003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10850 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-28 09:38:16 +00:00
mstarzinger@chromium.org
fb8eb04bfd Implement inlining of constructor calls.
R=vegorov@chromium.org,kmillikin@chromium.org

Review URL: https://chromiumcodereview.appspot.com/9304001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-28 09:05:55 +00:00
vegorov@chromium.org
6703dddac4 Support fast case for-in in Crankshaft.
Only JSObject enumerables with enum cache (fast case properties, no interceptors, no enumerable properties on the prototype) are supported.

HLoadKeyedGeneric with keys produced by for-in enumeration are recognized and rewritten into direct property load by index. For this enum-cache was extended to store property indices in a separate array (see handles.cc).

New hydrogen instructions:

- HForInPrepareMap: checks for-in fast case preconditions and returns map that contains enum-cache;
- HForInCacheArray: extracts enum-cache array from the map;
- HCheckMapValue: map check with HValue map instead of immediate;
- HLoadFieldByIndex: load fast property by it's index, positive indexes denote in-object properties, negative - out of object properties;

Changed hydrogen instructions:

- HLoadKeyedFastElement: added hole check suppression for loads from internal FixedArrays that are knows to have no holes inside.

R=fschneider@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9425045

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-22 12:47:42 +00:00
mstarzinger@chromium.org
1dd2b094a5 Implement fast literal support in Crankshaft.
This extends the current support for nested object literals we already
have in Crankshaft, to also support nested array literals and mixed
nested literals containing arrays and objects. All three types are
generated by the unified HFastLiteral instruction.

All previous upper bounds on nested literal graphs remain unchanged,
keeping the size of generated code in check.

The main intention is to boost performance of two-dimensional array
literals containing constant elements (aka. matrices).

R=danno@chromium.org
TEST=mjsunit/compiler/literals-optimized

Review URL: https://chromiumcodereview.appspot.com/9403018

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-16 17:32:30 +00:00
fschneider@chromium.org
0be449d684 Enable optimization of top-level code and generate deoptimization support lazily.
This change enables optimization of top-level and eval-code. For this to work, it adds
support for declaring global variables in optimized code.

At the same time it disables the eager generation of deoptimization support data
in the full code generator (originally introduced in
 r10040). This speeds up initial compilation and saves 
memory for functions that won't be optimized. It requires
 recompiling the function with deoptimization
 support when we decide to optimize it.

Review URL: https://chromiumcodereview.appspot.com/9187005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10700 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-14 14:14:51 +00:00
fschneider@chromium.org
86a0e828dc Remove a little more dead code from lithium-* files.
Review URL: http://codereview.chromium.org/9301040

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10571 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-31 15:00:13 +00:00
fschneider@chromium.org
c26695e75b Remove a dead method from lithium-* files.
Review URL: http://codereview.chromium.org/9297059

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10548 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-30 12:16:31 +00:00
yangguo@chromium.org
339c9c12e7 Inlining Math.min and Math.max in crankshaft.
BUG=v8:1325
TEST=

Review URL: http://codereview.chromium.org/9147034

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10391 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-11 15:43:33 +00:00
ager@chromium.org
d59749f8b4 Support inlining and crankshaft optimization of Math.random.
R=jkummerow@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/9167011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10384 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-11 10:35:37 +00:00
kmillikin@chromium.org
d8acc2dfbe Clean up handling of global cell stores in the optimizing compiler.
Tell the register allocator the value is not overwritten.  Never use
temporary registers on ia32, avoid them on x64 and ARM.  Restore the
original copyright date on assembler.cc.

R=fschneider@chromium.org
BUG=v8:1870
TEST=

Review URL: http://codereview.chromium.org/8965038

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10280 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-12-20 10:57:12 +00:00
yangguo@chromium.org
1bfa622043 Refactor MathPowHalf on ia32.
BUG=v8:397, v8:1848
TEST=regress-397.js

Review URL: http://codereview.chromium.org/8806010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10157 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-12-05 15:58:25 +00:00
fschneider@chromium.org
8f7a1f7808 Revert r10118 from bleeding edge.
It causes several test failures which I need to investigate.
Review URL: http://codereview.chromium.org/8769008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-12-01 16:57:54 +00:00
fschneider@chromium.org
4ca20a1d35 Simplify stack check instruction in Crankshaft.
So far we had two types of stack checks: one used for function entries
and one used at loop back edges which uses a deferred code object to
avoid spilling of registers in the loop.

After refactoring lazy deoptimization the first stack check can also
use deferred code. This change removes the first type of stack check
instruction in Crankshaft and uses a deferred stack check in all
places.
Review URL: http://codereview.chromium.org/8775002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-12-01 09:54:05 +00:00
keuchel@chromium.org
1e9a7267ab Introduce extended mode.
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.

The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.

This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
  ResolvePossiblyDirectEval, InitializeVarGlobal,
  DeclareGlobals

The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache

Review URL: http://codereview.chromium.org/8417035

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-24 15:17:04 +00:00
mstarzinger@chromium.org
7e7d4dfd64 Implement crankshaft support for nested object literals.
This generates optimized code for deep-copying of nested object literal
boilerplates which are statically known. Most of the boilerplates have
already been generated at crankshaft time, so this optimization should
kick in for virtually every object literal. Only nested object literal
graphs up to a certain depth and containing up to a certain total number
of properties are considered for this optimization. This will prevent
explosion of code size due to large object literals (e.g. eval on JSON).
Improves splay performance because object literals are created often.

R=fschneider@chromium.org

Review URL: http://codereview.chromium.org/8640001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-24 13:42:52 +00:00
fschneider@chromium.org
8fbf1d5017 Landing: [hydrogen] optimize switch with string clauses. Patch by Fedor Indutny <fedor.indutny@gmail.com>.
Original code review: http://codereview.chromium.org/8373029/
Review URL: http://codereview.chromium.org/8589019

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10019 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-17 13:57:55 +00:00
fschneider@chromium.org
8480569467 Fix lazy deoptimization at HInvokeFunction and enable target-recording call-function stub.
Changes the way we do lazy deoptimization:

1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.

     CALL
     GAP
     LAZY-BAILOUT ==> lazy-deopt-call

2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.

   STACK-CHECK
   GAP ==> lazy-deopt-call

The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.

Additional changes:
 * RegExpLiteral marked it as having side-effects so that it 
   gets an explicitlazy-bailout instruction (instead of
   treating it specially like stack-checks)
 * Enable target recording CallFunctionStub to achieve
   more inlining on optimized code.

BUG=v8:1789
TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js
Review URL: http://codereview.chromium.org/8492004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-16 08:44:30 +00:00
rossberg@chromium.org
f936aac43e Make _CallFunction proxy-aware.
Change calling convention for CallFunction stub.
Some fixes regarding strict mode call traps.

R=kmillikin@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/8318014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9916 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-08 14:39:37 +00:00
fschneider@chromium.org
4627023b38 Revert r9901 to make tree green again.
There was a test failure on x64 mozilla tests.

TBR=ricow@chromium.org
Review URL: http://codereview.chromium.org/8495011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-08 09:56:09 +00:00
fschneider@chromium.org
cac3008437 [hydrogen] optimize switch with string clauses
Hydrogen should optimize not only SMI clauses, but clauses with string literals
too.

Patch from fedor.indutny <fedor.indutny@gmail.com>.

R=vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8373029

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9901 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-08 09:08:33 +00:00
fschneider@chromium.org
f3f16dc17a Make non-templatized versions of LIR printing functions.
This avoid duplicating the code for each template instance.

Also remove dead code from different places in our code base.

Removed some verification code from release builds.
Review URL: http://codereview.chromium.org/8387070

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9860 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-02 08:32:40 +00:00
fschneider@chromium.org
d418a11fdd Use placement-new for zone-allocation in the Lithium classes.
This avoid calling Isolate::Current on each zone-allocation of
a Lithium object.
Review URL: http://codereview.chromium.org/8429001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9856 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-01 11:49:31 +00:00
fschneider@chromium.org
0df9569fe5 Merge IR classes for different bitwise operations AND, OR and XOR into one class.
Since we already have only one LIR class, it does not make much sense to separate
them at the HIR level.
Review URL: http://codereview.chromium.org/8426005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9846 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-31 13:06:26 +00:00
keuchel@chromium.org
c6464d500b Replace boolean indications of strict mode by an enum value.
Review URL: http://codereview.chromium.org/8344082

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9746 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-24 07:47:22 +00:00
jkummerow@chromium.org
3a9d6c04ba Introduce HTransitionElementsKind instruction.
TEST=mjsunit/elements-kind

Review URL: http://codereview.chromium.org/8305001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9702 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-19 12:10:18 +00:00
fschneider@chromium.org
2791cd5a2c Allow inlining of named function expressions containing ThisFunction reference.
Named function expression have an implicit local variable that
refers to the current function (ThisFunction). Before we only could inline
anonymous function expressions like:

A.prototype.foo = function() {}

as opposed to

A.prototype.foo = function foo() {}

This change enables inlining function of expressions like this.
Review URL: http://codereview.chromium.org/8346032

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9699 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-19 11:41:22 +00:00
fschneider@chromium.org
212e4ae7d4 Eliminate write barrier for global stores at compile time if value stored is a smi.
Omit smi check inside write barriers if the value is known to be a heap object.

Refine inferred types of some instructions.
Review URL: http://codereview.chromium.org/8256016

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9618 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-10-14 07:45:18 +00:00
kmillikin@chromium.org
bcb781d76a Record function call targets, use them for inlining.
Introduce a version of the CallFunctionStub that records monomorphic
call targets in a one-element cache in the instruction stream.  Use
the cache for inlining attempts in the optimizing backend.

R=fschneider@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/7966038

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9449 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-27 11:42:02 +00:00
whesse@chromium.org
2e40bc244a Add dynamic stack frame alignment to optimized functions with untagged doubles on the stack.
BUG=
TEST=

Review URL: http://codereview.chromium.org/7976024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-23 13:28:17 +00:00
kmillikin@chromium.org
22ef98dc66 Fix a deoptimization bug.
We reset the count of outgoing arguments, used for the index in the
frame's outgoing arguments, for each level of inlining.  This could
result in the arguments overlapping, rather than stacking on top of
each other.

R=whesse@chromium.org,fschneider@chromium.org
BUG=
TEST=

Review URL: http://codereview.chromium.org/7932022

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-20 07:14:30 +00:00
vegorov@chromium.org
ac36cb4504 Merge experimental/gc branch to the bleeding_edge.
Review URL: http://codereview.chromium.org/7945009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9328 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-19 18:36:47 +00:00
svenpanne@chromium.org
cf63503cad Unify the handling of comparinsons against null and undefined.
Although this patch is not small, most parts of it are rather mechanical:

 * First of all, the concept of a 'nil-like' value is introduced, which can be
   null or undefined. They are treated symmetrically regarding comparisons, so
   it makes sense to handle them in a uniform manner. It is a mystery why
   JavaScript defines two of those beasts, when even *one* is a design wart...

 * Extended and renamed a few things which now handle undefined in addition to
   null.

 * Made the parts of the full code generator and the hydrogen generation which
   deal with comparisons a bit more similar regarding their handling of special
   cases.

 * Refactored the syntactical detection of special cases for comparisons,
   hopefully making them a bit more readable and less copy-n-paste-oriented.
   Things like this should really be a one-liner in any sane programming
   language... :-P

 * Cut down the length of the argument lists of a few functions to something
   less insane, making them more easily understandable locally. This involves
   minor code duplication, but this was a good tradeoff and can be remedied
   later if necessary.

 * Replaced some boolean arguments with more readable enums.

 * Fixed a TODO: Values which are definitely a Smi or unboxed can never be equal
   to null or undefined.
Review URL: http://codereview.chromium.org/7918012

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9323 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-19 14:50:33 +00:00
danno@chromium.org
9b2de409f9 Mechanical refactor to move ElementsKind type out of JSObject.
R=svenpanne@chromium.org
BUG=none
TEST=all

Review URL: http://codereview.chromium.org/7849017

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9208 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-09-09 09:35:57 +00:00
jkummerow@chromium.org
9295a3a0bb Use immediates when possible for HBoundsCheck and HLoadKeyedFastElement
Review URL: http://codereview.chromium.org/7608020

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8943 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-16 13:32:27 +00:00
danno@chromium.org
d5d7185578 Create a common base class for Fixed-, FixedDouble- and ExternalArrays.
Also unify Crankshaft code to load array length.

BUG=v8:1493
TEST=external-arrays.js

Review URL: http://codereview.chromium.org/7600025

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8901 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-08-11 14:00:16 +00:00
svenpanne@chromium.org
e48ec1c4bd Use type info for the ToBoolean translation in crankshaft.
To do this, the Branch instruction needs to carry around a temporary register,
but only when the crankshafted code will make a map access. When the
crankshafted code sees an object of a type it hasn't encountered before, it will
always trigger a deopt. Another option in theses cases would be calling a
ToBooleanStub which can handle all types, but then one has to be careful to
*not* trigger a GC (which is currently a bit tricky to achieve).

Const-corrected ToBoolean::Types. Moved the NeedsMap logic into ToBoolean::Types
itself, where it belongs.

This patch improves a lot of benchmarks, crypto-orig even by 16.7%, but slows
down others. The slowdown has to be investigated, but I'd like to get this patch
out first to fix the flakiness problems we currently have due to the previous
crankshafted ToBoolean.
Review URL: http://codereview.chromium.org/7461107

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8758 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-07-28 13:33:51 +00:00
danno@chromium.org
11c7b47430 Crankshaft support for FixedDoubleArrays
BUG=none
TEST=unboxed-double-arrays.js

Review URL: http://codereview.chromium.org/7350021

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-07-19 13:04:00 +00:00
whesse@chromium.org
f3d1453f83 As part of allowing different contexts for inlined functions, eliminate most explicit reads of the context from the stack frame in ia32 crankshaft codegen.
Eliminates the enum flag RESTORE_CONTEXT and CONTEXT_ADJUSTED, and adds a context HValue and LOperand to many hydrogen and lithium instructions.

Context is still used from the stack from in CallKnownFunction (this seems safe), and in CallRuntimeFromDeferred in lithium-codegen-ia32.cc, which needs to be fixed.

BUG=
TEST=

Review URL: http://codereview.chromium.org/7132002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8529 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-07-04 14:13:08 +00:00
fschneider@chromium.org
b12e933e43 Refactor handling of test expressions in the graph builder.
Instead of generating two instructions and combining them
at lithium translation using the EmitAtUses predicate, we
generate the correct branch instruction right from the start.
Review URL: http://codereview.chromium.org/7237024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8495 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-30 14:19:52 +00:00
fschneider@chromium.org
2760bd2927 Slightly improved register assignment for %_IsObject on IA32 and ARM.
The new approach uses one temp register instead of two on IA32. The ARM
instructions are modified so the input can be UseAtStart again.
Review URL: http://codereview.chromium.org/7274025

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8451 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-28 14:21:55 +00:00
sgjesse@chromium.org
54d6072332 Change the handling of stack check on backward branches
The hydrogen stack check instruction is now added to each loop and the stack check handling on the back edge has been removed.

This change causes regression on small tight loops as the stack check is now at the top of the loop instead of at the bottom, and that requires one additional unconditional jump per loop iteration. However the reason for this change is to avoid worse regressions for upcoming changes to correctly support debugger break in optimized code.

R=fschneider@chromium.org

BUG=none
TEST=none

Review URL: http://codereview.chromium.org//7216009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-27 12:12:27 +00:00
fschneider@chromium.org
01a8cda43e Remove redundant hydrogen- and lithium instruction for symbol comparison.
We had two instructions HCompareJsObjectEq and HCompareSymbolEq that behave
exactly the same. I removed one and renamed the remaining instruction into
HCompareObjectEq.
Review URL: http://codereview.chromium.org/7206040

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8349 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-06-21 11:18:15 +00:00