https://chromiumcodereview.appspot.com/10825071/diff/1/src/hydrogen-instructions.cc File src/hydrogen-instructions.cc (right):
https://chromiumcodereview.appspot.com/10825071/diff/1/src/hydrogen-instructions.cc#newcode1151 src/hydrogen-instructions.cc:1151: if (change->value()->IsDiv() && On 2012/07/30 16:43:13, Evan Wallace wrote:
These aren't the only conditions that trigger this optimization. It
must also be
the case that both operands are integers, the dividend is
non-negative, and the
divisor is positive. This ensures that the result of the division can
always be
representable as an integer and that the deopt will never be hit. For
example,
with the following HIR:
d3 = Div i1, i2 i4 = Change d to i d3
The preconditions are: - i1 is an int32 in range [a, b] where 0 <= a <= b <= kMaxInt - i2 is an int32 in range [c, d] where 1 <= c <= d <= kMaxInt
Thus the range of the result is [a / d, b / c] which can always be
safely
truncated to int32 range since: - 0 <= a / d <= a - 0 <= b / c <= b - a / d <= b / c
I don't dispute that it can be truncated to int32. My concern is that it can necessarily be represented as int32 e.g. 1/2 can be truncated to int32 but it is not representable in int32. Normal Change d -> i is not truncating, it will deopt on non-integer values (which corresponds to non-zero remainder). What do you think about limiting this optimization to truncating Change instructions? I suspect we can mark store into int32/int16/int8 array (and associated Change) as truncating. https://chromiumcodereview.appspot.com/10825071/diff/1/src/hydrogen-instructions.cc#newcode1159 src/hydrogen-instructions.cc:1159: if (div->UseCountIgnoringInputsRequiringNone() == 1) { On 2012/07/30 16:43:13, Evan Wallace wrote:
Thanks for pointing this out! I guess I don't understand HSimulate
then. I
needed it for the case in my example of updating an element in a typed
array
"x[0] = 0xFF / (x[0] + 1)" but that can be done instead by using "x[0]
= 0 |
0xFF / (x[0] + 1)", which doesn't generate a HSimulate pointing to the
HDiv.
I'll change this to require an absolute use count of 1 instead.
Simulate is a pseudo-instruction that "simulates" changes that happen with the state of unoptimized code corresponding to a particular position in optimized code. It is needed to compute how stack frames would look like for unoptimized code when we deopt. One can say that simulates delta-encode deoptimization environments as each simulate describes what observable changes happened to the state since the previous simulate: what was stored into local variables, what was pushed to expression stack or how many values were poped from it. Uses at simulate describe what unoptimized code will see if deopt happens between this simulate and the next one. https://chromiumcodereview.appspot.com/10825071/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
