This fixes materialization of arguments objects for strict mode functions during
deoptimization. We materialize arguments from the stack area where optimized
code pushes the arguments when entering the inlined environment. For adapted
invocations we use the arguments adaptor frame for materialization.
R=svenpanne@chromium.org
BUG=v8:2261
TEST=mjsunit/regress/regress-2261,mjsunit/compiler/inline-arguments
Review URL: https://chromiumcodereview.appspot.com/10908194
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Safe operations are those that either do not observe unsignedness or have special support for uint32 values:
- all binary bitwise operations: they perform ToInt32 on inputs;
- >> and << shifts: they perform ToInt32 on left hand side and ToUint32 on right hand side;
- >>> shift: it performs ToUint32 on both inputs;
- stores to integer external arrays (not pixel, float or double ones): these stores are "bitwise";
- HChange: special support added for conversions of uint32 values to double and tagged values;
- HSimulate: special support added for deoptimization with uint32 values in registers and stack slots;
- HPhi: phis that have only safe uses and only uint32 operands are uint32 themselves.
BUG=v8:2097
TEST=test/mjsunit/compiler/uint32.js
Review URL: https://chromiumcodereview.appspot.com/10778029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12367 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple setter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the setter is not
handled at all. Because of the latter, we temporarily hide this feature behind
the --inline-accessors flag, just like inlining getters.
We now use an enum everywhere we depend on the handling of a return value,
passing around several boolean would be more confusing.
Made VisitReturnStatement and the final parts of TryInline more similar, so
matching them visually is a bit easier now.
Simplified the signature of AddLeaveInlined, the target of the HGoto can simply
be retrieved from the function state.
Review URL: https://chromiumcodereview.appspot.com/10836133
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12286 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only handles when x is int32 and y is int32 constant.
BUG=v8:2038
Currently implemented by imul (not fpmul).
x86 and x64 algorithm differs a bit.
x86 implementation is kind of cumbersome, but I couldn't think of better ways.
Review URL: https://chromiumcodereview.appspot.com/10382033
Patch from Zheng Liu <zheng.z.liu@intel.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11887 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Extend HValue interface to allow splitting observed input representation (comming from type feedback) from required input representation (dictated by instruction itself). Currently all instructions except for bitwise binary operations have this representations match. For bitwise binary operations hydrogen builder unconditionaly forces Integer32 representation for those operations that have Double type feedback. Thus causing representation inference to incorrectly count such uses as Integer32 instead of Double. This change also prepares for more fine grained type feedback for inputs of binary operations.
- For phies that are not convertable to Integer32 discard direct and indirect use count of Integer32 type to avoid propagation of these uses to connected phies.
R=jkummerow@chromium.org
BUG=v8:2096
Review URL: https://chromiumcodereview.appspot.com/10540049
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11737 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When an array index (in an array access) is a simple "expression + constant", just embed the constant in the array access operation so that the full index expression is (potentially) no longer used and its live range can be much shorter.
This is effective in conjunction with array bounds check removal (otherwise the index is anyway used in the check).
Review URL: https://chromiumcodereview.appspot.com/10382055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change allows hydrogen instructions to keep track of instructions
that dominate certain side-effects (GVN flags) in the hydrogen graph. We
use the GVN pass to keep track of side-effects because accurate flags
are already in place.
It also adds a new side-effect (kChangesNewSpacePromotion) indicating
whether an instruction can cause a GC and have objects be promoted to
old-space. An object allocated in new-space is sure to stay on paths not
having said side-effect.
R=erik.corry@gmail.com
TEST=mjsunit/compiler/inline-construct
Review URL: https://chromiumcodereview.appspot.com/10031031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Lithium translation rebuilds hydrogen environments from scratch so we have to ensure that arguments object is correctly bound on function entry otherwise deoptimization will not materialize it.
This fix was implemented as part of r11109 and then reverted.
R=danno@chromium.org
BUG=v8:2045
TEST=test/mjsunit/regress/regress-2045.js
Review URL: https://chromiumcodereview.appspot.com/9963008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The old code used a separate HToInt32 instruction which had a wrong register
constraint for the input register which caused wrong result when the stored value
is used after a typed array store. (UseRegister instead of UseTempRegister) when no
SSE3 is available.
This change fixes it by replacing HToInt32 with the corresponding HChange
instruction which has correct register contraints.
TEST=mjsunit/compiler/regress-toint32.js
Review URL: https://chromiumcodereview.appspot.com/9565007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10891 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL is a step towards removing ZoneObject's new operator without a Zone
parameter, which uses Isolate::Current. For e.g. the bulletben benchmark, this
CL reduces the number of calls to this new operator by roughly 120k, but we are
still left with 780k calls from other sites...
Review URL: https://chromiumcodereview.appspot.com/9487010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10860 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
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
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Committed: http://code.google.com/p/v8/source/detail?r=10331
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds support for loading from and storing to context slots
belonging to harmony let or const bound variables. Checks for the
hole value are performed and the function is deoptimized if they fail.
The full-codegen generated code will take care of properly throwing
a reference error in these cases.
TEST=mjsunit/harmony/block-let-crankshaft.js
Review URL: http://codereview.chromium.org/8820015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
This shaves 416+ KB, just under 1% off the size of the debug d8 executable
on Linux (mostly because the CheckHelper functions for assertions were
getting separate copies for each compilation unit). The difference in
release builds is negligible---a size reduction of 0.1%.
Also, change namespace-level 'static const' variables to remove the static
storage class as it's the default.
R=danno@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8680013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10083 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
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
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
This time, we initially leave the HTypeof instruction in the Hydrogen graph,
even for the special cases. We later try to remove this instruction (and any
HConstant) in the canonicalization pass, if possible. Always removing the
HTypeof during the initial graph construction is wrong if e.g. it is used in an
HSimulate.
The removals can be generalized a bit, but this will happen in a separate CL.
TEST=mjsunit/optimized-typeof.js
Review URL: http://codereview.chromium.org/8334021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9688 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently we avoid checking for the hole value after array loads, if the
result is only used by instructions that definitely deoptimize in case
of the hole value (HChange instructions).
This change performs the same procedure for loading from deleteable/read-only
global variable where we can also avoid the check in the same cases.
Review URL: http://codereview.chromium.org/8054008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9453 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
When we propagate the information that a value is not convertible to integer,
there is no need for a separate fixed-point computation, we can do things the
"Millikin way" (tm), folding as much computation as possible into a single pass:
;-) We already have the phi node reachability information, so we can easily
propagate this while doing the representation histogram computation.
Review URL: http://codereview.chromium.org/7754010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9212 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This improves our static type information by calculating the result type
of conversions (HChange) during range analysis. It allows e.g. to eliminate
the write barrier in the following example where it was not possible before:
function f(x) {
var y = x + 1;
if (y > 0 && y < 100) {
a[0] = y;
}
}
* Fix bug in Range::Copy. The minus-zero flags has to be preserved by default.
Review URL: http://codereview.chromium.org/7634022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Some AST nodes (Property, Call, etc.) store either a list of receiver
types or a monomorphic receiver type. This patch merges the two fields
using a small pointer list. GetMonomorphicReceiverType() is now a
purely convenience function returning the first and only recorded
type.
This saves about 500K (of about 39M) on average when compiling V8
benchmark as measured by a simple patch adding a zone allocation
counter (https://gist.github.com/1149397).
R=kmillikin@chromium.org
Review URL: http://codereview.chromium.org/7655017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8993 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is available platforms that have SSE 4.1 and allows us to handle
negative numbers without deoptimization. Before we would deoptimize
on negative inputs to Math.floor. x64 already uses this instruction.
* Change Math.floor unit test to make sure every test case gets
optimized by changing the source code for each test case.
* Fix HIR debug printing for some instructions.
Review URL: http://codereview.chromium.org/7628017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the input range is positive and the shift count is constant
we can replace >>> with >> to compute the output range.
For negative inputs, we can only compute a range if the
result always fits into a signed int32.
BUG=v8:1510
Review URL: http://codereview.chromium.org/7489043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8735 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/hydrogen-instructions.h (HClampToUint8): Don't mark as having
flexible representation; instead the output is always an Integer32.
There is no input representation restriction, so we can still perform
input-specific truncation.
I tested by looking at the --print-code of
var a = PixelArray(1000000)
function fill(a,x) { for (var i=0; i<a.len; i++) a[i] = x; }
Seems to optimize fine both for double and integer inputs. But perhaps
there is a better test, for which the original code does better, and
this is a bogus patch.
Review URL: http://codereview.chromium.org/7357003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8650 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/hydrogen.cc (HInferRepresentation::Analyze): Fix iterative loop
over phis; the shortcutting behavior of || appears to be accidental
here, causing O(n^2) convergence. Not that it matters much, but hey!
While I'm at it, a minor comment fix:
* src/hydrogen-instructions.h (EnsureAndPropagateNotMinusZero): Fix a
comment about the kinds of instructions that propagate to multiple
inputs.
BUG=
TEST=passes tools/test.py
Review URL: http://codereview.chromium.org/7350019
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8645 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
This change makes the number of successors of a control instruction
configurable with a template parameter and changes the existing instructions
to use it.
To iterate over all successors I added an iterator instead of always calling
First- and SecondSuccessor.
Review URL: http://codereview.chromium.org/7114004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8262 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If type-feedback indicates that an expression was never executed in
the non-optimized code, we insert a forced deoptimization right away
to enable re-optimization if we ever hit this path.
With this change we still continue to build the graph. As a next step, we
should remove the dead code after the deoptimize.
I had to remove one assert about the optimization status in a test since
we now immediately deoptimize after exiting the loop that triggers OSR.
Also remove a restriction that control-flow from an inlined function in a
test context always reaches both true- and false-target.
Review URL: http://codereview.chromium.org/7105015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Introduce a class JSReceiver, that is a common superclass of JSObject and
JSProxy. Use JSReceiver where appropriate (probably lots of places that we
still have to migrate, but we will find those later with proxy test suite).
- Move appropriate methods to JSReceiver class (SetProperty,
GetPropertyAttribute, Get/SetPrototype, Lookup, and so on).
- Introduce new JSFunctionProxy subclass of JSProxy. Currently only a stub.
- Overhaul enum InstanceType:
* Introduce FIRST/LAST_SPEC_OBJECT_TYPE that ranges over all types that
represent JS objects, and use that consistently to check language types.
* Rename FIRST/LAST_JS_OBJECT_TYPE and FIRST/LAST_FUNCTION_CLASS_TYPE
to FIRST/LAST_[NON]CALLABLE_SPEC_OBJECT_TYPE for clarity.
* Eliminate the overlap over JS_REGEXP_TYPE.
* Also replace FIRST_JS_OBJECT with FIRST_JS_RECEIVER, but only use it where
we exclusively talk about the internal representation type.
* Insert JS_PROXY and JS_FUNCTION_PROXY in the appropriate places.
- Fix all checks concerning classification, especially for functions, to
use the CALLABLE_SPEC_OBJECT range (that includes funciton proxies).
- Handle proxies in SetProperty (that was the easiest part :) ).
- A few simple test cases.
R=kmillikin@chromium.org
Review URL: http://codereview.chromium.org/6992072
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The approach is to handle the common case in the optimizing
compiler and to bailout for the rare corner cases.
This is done by initializing all local const-variables with
the hole value and disallowing any use of the hole value statically.
Review URL: http://codereview.chromium.org/6026006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8104 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only IA32 version for now. I'll start porting.
Strict mode functions are to get 'undefined' as the receiver when
called with an implicit receiver. Modes are bad! It forces us to have
checks on all function calls.
This change attempts to limit the cost by passing information about
whether or not a call is with an implicit or explicit receiver in ecx
as part of the calling convention. The cost is setting ecx on all
calls and checking ecx on entry to strict mode functions.
Implicit/explicit receiver state has to be maintained by ICs. Various
stubs have to not clobber ecx or save and restore it.
CallFunction stub needs to check if the receiver is implicit when it
doesn't know from the context.
Review URL: http://codereview.chromium.org/7039036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8040 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If a HDeoptimize does not cut away parts of the control-flow-graph
we don't need to insert uses to correctly elimiate dead phis since
the full function is visible to the optimizing compiler.
This is a small improvement of the change r7221 which fixed a problem
when deoptimizing on never executed case-clauses.
Review URL: http://codereview.chromium.org/7012010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows us to get rid of totally fake LAST_STRING_TYPE and makes
it possible to test for symbols.
I considered splitting HCheckInstanceType into two instructions, but
it seems nice to be able to hide the instance type implementation
details from the hydrogen level.
Review URL: http://codereview.chromium.org/6964011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7840 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the result of an fast elements load is converted to an untagged
representation we can omit the hole check if the value is not used
anywhere else except for HChange instructions converting it to
an untagged representation since those will deoptimize for the hole
value anyway.
Review URL: http://codereview.chromium.org/6964012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7827 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Use a special slot for HContext, and fetch the value from there each time it is used. Allocate space for special slots in every HEnvironment. Fill them with constant undefined. Do not copy them to LEnvironment.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6929066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7807 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Until now we conservatively chose a double representation if
at least one use occurs in a double operation. This causes performance
degradation in many cases where there are mixes uses (integer and double)
e.g.:
for (int i = 0; i < 10; i++) {
var t = i / 3.5;
a[i] = t;
}
where the use in i/3 requires a double, where as the keyed store requires i
as an integer.
For these cases we want to have i as an integer and convert it only before the
double division.
In order to avoid unconditional deoptimization in some rare cases, we check
phis if there is any conversion that will always fail when converting a
heap-number constant to int32.
Review URL: http://codereview.chromium.org/6905166
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7757 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Rather than representing a use as a pointer to an HValue and then searching
for the specific (ambiguous) operand, we now represent a use as a pair of an
HValue and the input operand index. Additionally, use a linked list instead
of a growable array list since we never use random access.
This allows us to remove a bunch of similarly named and subtly different
functions from the HValue API. The cost in extra zone allocation per use is
partially offset by reusing use list nodes when replacing a use of one value
with another.
R=danno@chromium.org,fschneider@chromium.org
Review URL: http://codereview.chromium.org/6881044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7674 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of using virtual type-tester functions we can just
generate non-virtual ones for all concrete IR classes.
This is changes reduces the V8 binary size by ~2%.
I also simplified the macros to declare new hydrogen instructions slightly.
The name used for debug output is no longer passed as a separate string.
Instead we just use the class name.
Review URL: http://codereview.chromium.org/6880014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7659 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- mutual inlining strict and non-strict functions in crankshaft.
- assignment to undefined variable with eval in scope.
- propagation of strict mode through lazy compilation.
BUG=
TEST=test/mjsunit/strict-mode.js test/mjsunit/strict-mode-opt.js
Review URL: http://codereview.chromium.org/6814012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7561 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the cases where a global property cell cannot be used in the optimized code
use standard load ic to get the property instead of bailing out.
This is re-committing r7212 and r7215 which where reverted in r7239 with the addition of recoring the source position in the hydrogen code for the LoadGlobalCell instruction. To record that position an optional position field has been added to the variable proxy AST node.
Review URL: http://codereview.chromium.org/6758007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change adds a new IR instruction for polymorphic loads. It performs
map compares and loads in one IR instruction instead of splitting each
load into a graph of map-compares and field loads.
The advantage is a smaller IR and less basic blocks, plus it allows to
do GVN on polymorphic loads.
Review URL: http://codereview.chromium.org/6708085
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows fast calls and inlining of functions like:
var o = {f: function() { return "foo"; }}
o.f();
Object literals that contain function literals are initially created a dictionary mode
object and only transformed to fast properties once all properties are computed and
added. This allows us to create constant function properties for functions declared
inside the object literal. Function literals inside object literals are marked for
pretenuring so that they work as contant function properties.
Object literals without functions should just function as before.
Review URL: http://codereview.chromium.org/6240012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7283 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Worth mentioning:
- Specialized versions of pixel array and store/loads inside the generic stubs have been removed, since to have parity for all external arrays, 8 different versions would have to be inlined/checked.
- There's a new constant in v8.h for external arrays with pixel array elements.
Review URL: http://codereview.chromium.org/6546036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Before we would compute the flag by iterating over all uses. The truncating
flag is always determined at construction time since we already computed
the flag for all other instructions before inserting HChange instructions.
Review URL: http://codereview.chromium.org/6615012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The class did not correctly implement the RequiredInputRepresentation.
I changed this functions to be abstract so that all hydrogen classes
must implement it.
As a convention instructions with zero input operands return None as input
representation.
Instructions that can handle all input representations without converting before
also have None as required input representation (e.g. HTest)
All other instructions need a proper required input representation.
Review URL: http://codereview.chromium.org/6538088
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6891 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
