Once we crankshaft a method, we should turn off allocation site info for
constructed arrays. Additionally, the semantics for doing this were
awkward because the constructed array code stubs get an
AllocationSiteMode as a minor key, but it's used as a permission to
determine the final mode locally based on ElementsKind. I refactored
this to a simpler boolean for override or local control.
BUG=
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/16206007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14934 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- For now, just adds the missing type info fields to the AST nodes directly.
I'd like to factor that out more nicely in a follow-up CL.
- All type feedback now is uniformly collected through AST nodes'
RecordTypeFeedback functions. At some point, this logic should be moved
out of ast.cc.
- The typing pass currently simulates the exact same conditions under
which feedback was collected in Hydrogen before. That also should be
made more generic in the future.
- Type information itself is unchanged. Making it more regular is
yet more future work.
Some additional cleanups:
- Lifted out nested class ObjectLiteral::Property, to enable forward declaration.
- Moved around some auxiliary enums.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/14990014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14825 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Addition of a compiled hydrogen stub for KeyedStores.
- Inlining of "grow" stubs into OPTIMIZED_FUNCTIONs
- Addition of new "ignore OOB" ic stub that silently swallows out-of-bounds stores to external typed arrays.
- Addition of new "copy-on-write" ic stub that inlines allocation and copying operations for cow array
- New stub are generated with Crankshaft, so they are automatically inlined into OPTIMIZED_FUNCTIONs
Review URL: https://codereview.chromium.org/12221064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14001 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows Crankshaft to completely inline a f.apply() dispatch if the
exact number of arguments is known and the function is constant. The
deoptimizer doesn't generate the f.apply() frame during deoptimization,
so the materialized frames look like f.apply() did a tailcall.
R=jkummerow@chromium.org
TEST=mjsunit/compiler/inline-function-apply
Review URL: https://codereview.chromium.org/12263004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
With parallel recompilation enabled, objects made accessible by handles may
have changed between graph construction and graph optimization. Therefore
we must not assume that information on those objects remain the same between
those two phases. To police this, we forbid handle dereferencing during
graph optimization.
Exceptions to this rule are:
- Dereferencing the handle to obtain the raw location of the object. This
is safe since parallel recompilation acquires RelocationLock
- Some places that dereference the handle for a type check. These are checked
to be safe on a case-by-case basis.
R=jkummerow@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/12049012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13475 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reduces the time take for mjsunit/limit-locals from 56.8s to 15.1s in debug
mode and from 12.0s to 1.6s in release mode.
Note that GrowableBitVector and BitVector should really be merged, and probably
have their allocation strategy parmeterized. The current state of affairs
involving tons of checks and delegation is extremely ugly, and it is far from
clear if all that special casing is a clear win. STL FTW! :-P
Review URL: https://codereview.chromium.org/11775016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13327 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We iteratively remove all dead Hydrogen instruction until we reach a fixed point. We consider an instruction dead if it is unused, has no observable side effects and is deletable. The last part of the condition is currently not very nice: We basically have to whitelist "safe" instructions, because we are missing more detailed dependencies and/or more detailed tracking of side effects.
We disable dead code elimination for now in our test runners, because we have tons of poorly written tests which wouldn't test anymore what they are supposed to test with this phase enabled. To get test coverage for dead code elimination itself, we should enable it on a few build bots. This is not really a perfect state, but the best we can do for now.
This patch includes a few const-correctness fixes, most of them were necessary for this CL.
Review URL: https://codereview.chromium.org/11088027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12697 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
