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
When inlining is being done, it is crucial to use the correct type feedback
oracle with a given type feedback ID. To ensure this, TestContext now carries an
oracle which is associated with the context's condition, and these are both used
together in TestContext::BuildBranch.
Note that in VisitReturnStatement and TryInline we are currently lucky that the
oracles don't go out of sync in an observable way, but this will change when we
inline setters. Therefore, there is no separate test case...
Review URL: https://chromiumcodereview.appspot.com/10834247
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12284 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple getter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the getter is not
handled at all. Because of the latter, we temporarily hide this feature behind a
new flag --inline-accessors, which is false by default.
Review URL: https://chromiumcodereview.appspot.com/10828066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a refactoring-only CL and the third one in a series for enabling
inlining of accessors. The goal of this CL is to move the builders for accessors
to the places where we might be able to inline them later, i.e. the VisitFoo and
HandleBar member functions of HGraphBuilder.
Extracted duplicate code into LookupAccessorPair.
Review URL: https://chromiumcodereview.appspot.com/10831047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12209 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a refactoring-only CL and the first one in a series for enabling
inlining of accessors. The naming and argument order has been unified a bit, and
some tests have been pushed to the caller in order to get a simpler
signature. Note that the latter temporarily introduces some code redundancy, but
this will be cleaned up in one of the next CLs.
Review URL: https://chromiumcodereview.appspot.com/10826028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12198 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The CompilationInfo record now saves a Zone, and the compiler pipeline
allocates memory from the Zone in the CompilationInfo. Before
compiling a function, we create a Zone on the stack and save a pointer
to that Zone to the CompilationInfo; which then gets picked up and
allocated from.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10534139
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11877 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
As a special case, for checks on index expressions with the form (expr + constant) if a smaller constant is checked later in the DT also eliminate the check.
Finally, if a larger constant is checked later in the same BB do the more general check (larger constant) earlier instead of the less general one.
This will not cause useless deoptimizations because, since we are in the same BB, all the checks would have been executed anyway.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10032029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11437 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Do proper dispatch on declaration type instead of mingling together
different code generation paths. Once we add more declaration forms,
this is more scalable.
In separate steps, I'd like to (1) clean up the logic for DeclareGlobal,
and (2) try to reduce the special handling of the name function var if
possible.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9704054
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11331 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
Modify PreProcessOsrEntry to work with OSR entries that have non-empty expression stack.
Modify graph builder to take for-in state from environment instead of directly referencing emitted instructions.
Extend %OptimizeFunctionOnNextCall with an argument to force OSR to make writing OSR tests easier: %OptimizeFunctionOnNextCall(f, "osr").
R=fschneider@chromium.org
TEST=test/mjsunit/compiler/optimized-for-in.js
Review URL: https://chromiumcodereview.appspot.com/9431030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10796 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 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
Until now we only could inline as specialized HIR instructions when called
as a method (e.g. Math.abs)
It is very common practice to abbreviate calls to those functions by defining
a global or local variable like:
var a = Math.abs;
var x = a(123);
This change allows inlining them when called as a function (global or local).
Review URL: https://chromiumcodereview.appspot.com/9365013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10640 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 change fixes a off-by-one level error when dropping the
function from the environment. The function of the outermost
environment was not dropped.
BUG=v8:1785
TEST=test/mjsunit/compiler/regress-inline-callfunctionstub.js
Review URL: http://codereview.chromium.org/8341019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9789 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change is based on my previous change enabling inlining calls-as-function
fixing the bugs related to deoptimization.
The function value on top of the environment was dropped too late in the old code.
As a result we could get a wrong value on top after deoptimization.
This change includes r9619. It was reverted because of test failures that are fixed
with this patch.
Review URL: http://codereview.chromium.org/8360001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9758 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
Previously, comparisons against null/undefined and comparisons of the result of
typeof against a constant string were done syntactically. Now we do this via
pattern matching on the hydrogen graph, which opens up more opportunities for
better code generation, e.g. the following comparisons are now recognized to be
special:
var bar = typeof foo;
var baz = "undefined";
if (bar == baz) ...
var blah = undefined;
if (hurz == blah) ...
If we did this handling of special cases even later at lithium generation time,
even more cases could be recognized, but this would involve bigger changes and
this CL handles most common cases.
Review URL: http://codereview.chromium.org/8242002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This eliminates compile-errors when assigning Handle<SerializedScopeInfo> to
Handle<Object> in a place where the declaration was not available because
variables.h was not included.
As a result I had to also move the enum Variable::Mode to v8globals.h and
rename it to VariableMode.
Review URL: http://codereview.chromium.org/8221004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We have to check for uninitialized uses before phi-elimination. Otherwise we
may miss such a use and result in using the hole value instead. This
causes a NULL-dereference or assertion failure.
BUG=96989
TEST=mjsunit/compiler/regress-96989.js
Review URL: http://codereview.chromium.org/7974009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9337 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
The Great Master Plan is to move the recognition of special cases for
comparisons further down the compilation pipeline where more information is
available. This is a first step into this direction: The special handling of
equality comparisons involving null is pushed from the parser to the code
generators, removing the need for a special AST node. (There are rumors from
usually well-informed sources that this node type is actually a relic of ancient
crankshaft days...)
The next steps will be the unification of null/undefined handling and pushing
the special case handling in crankshaft even further down the pipeline, enabling
the recognition of cases like "var foo=null; if (foo === bar) ...", but these
will be in separate CLs.
Review URL: http://codereview.chromium.org/7887037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9293 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The changes to scopes and parser introduce a VariableProxy
wrapping the function-name variable for function literals.
It seems the easiest way to get an AST id for the HSimulate
after context-slot stores in declarations.
Review URL: http://codereview.chromium.org/7826009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9112 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
HGraphBuilder::TryArgumentsAccess does not emit any uses for receiver and will generate incorrect code when receiver for a property access is defined by a phi that returns either arguments object or something else.
BUG=v8:1582
TEST=test/mjsunit/regress/regress-1582.js
Review URL: http://codereview.chromium.org/7553006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8774 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debugger can be entered from the deferred stack check in optimized code. This can cause both lazy deoptimization and debugger deoptimization (setting the first break point and inspecting the stack for optimized code respectively). This required deoptimization support from the deferred stack check.
The lazy deoptimiztion call is inserted when the deferred code is done including restoring the registers. The bailout to the full code is the begining of the loop body as that is where the stack check is sitting in the optimized code. The bailout is not to the stack check in the full code as that is sitting at the end of the loop.
R=kmillikin@chromium.org
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//7212025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8535 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
* src/hydrogen.cc (HEnvironment::CopyForInlining): As the code for both
the ::HYDROGEN and ::LITHIUM compilation phases is the same, just use
one code path and remove the arg.
* src/hydrogen.h (HEnvironment): Remove now-unused CompilationPhase
enum type and arg to CopyForInlining.
* src/arm/lithium-arm.cc (LChunkBuilder::DoEnterInlined):
* src/ia32/lithium-ia32.cc (LChunkBuilder::DoEnterInlined):
* src/x64/lithium-x64.cc (LChunkBuilder::DoEnterInlined): Adapt
callers.
* AUTHORS: Add Igalia.
BUG=
TEST=I ran tools/test.py.
Review URL: http://codereview.chromium.org/7272002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8442 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
Detect the pattern in both, the full compiler and crankshaft and generate direct pointer
comparisons. Along the way I cleaned up 'typeof <expression> == <string literal>' comparisons
as well by lifting platform independent code and checking the symmetric case.
BUG=v8:1440
TEST=cctest/test-api.cc
Review URL: http://codereview.chromium.org/7216008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8420 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* AST Expression nodes get a separate testing ID to record type info in
ToBooleanStub later. This is necessary to avoid clashes with other uses of
already existing IDs.
* In order to avoid threading the condition expression through tons of places,
TestContexts carry it now with them. Note that we will probably only need the
testing ID of the expression, but having the whole thing at hand makes
debugging easier. Probably we will change this later...
Review URL: http://codereview.chromium.org/7046073
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8274 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
Mainly, there were errors concerning blank lines before and after class access
control sections [whitespace/blank_line].
BEFORE an access control section (e.g. public:, private:) there should be a
blank line (except for the section right after the class declaration).
AFTER an access control section there should be no blank line.
TBR=ager@chromium.org
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8193 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
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
When descending the dominator tree we used to collect side effects from all blocks between the dominator and the dominated blocks in the block ordering. This could include blocks that do not appear on paths from the dominator to the dominated and unnecessarily removed available values from the GVN map.
Review URL: http://codereview.chromium.org/7036010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7943 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
onto a sinlge 30" screen. A lot of times, the AST visitor stops a bit too early,
so we have to do the rest of the dispatch by hand. This is caused by the fact
that the kind of the AST nodes are a bit too coarse for some traversals (e.g. a
single node type for all binary ops), perhaps one could try to refine this a
little bit more.
Review URL: http://codereview.chromium.org/6963008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7839 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
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
- 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
Fix %NewObjectFromBound to correctly handle optimized frames (including those with inlined functions).
Fix %_IsConstructCall handling in hydrogen: when called from inlined function return false constant directly instead of emiting HIsConstructCall.
Fix success case in TraceInline.
BUG=v8:1229
TEST=test/mjsunit/regress/regress-1229.js
Review URL: http://codereview.chromium.org/6740023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7472 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