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
