+danno Oh, I see. HIR for
x[0] = 0xFF / x[0]; would look like d2 = Div d0 d1 i3 = Change d2 d to i truncating-int32 StoreKeyedSpecializedArrayElement x4.int[i5] = i3 Simulate push d2 ;; confusing simulate that forces us to preserve double value by making us to think that it can be observed. This last simulate that pushes right-hand-side of assignment seems to be an unpleasant artifact of our graph construction. I don't see why we don't drop it because there is no way the value would actually be used by unoptimized code. But that seems to require a big refactoring in both graph builder and unoptimized code generator. It seems we have a choice: 1) We can agree to limit this optimization to the case where programmer explicitly coerces value to int32: x[0] = (0xFF / (x[0] + 1)) | 0; (it'll already be a step forward, and if the way we build graph and compile unoptimized code is later refactored to eliminate a rogue simulate then a normal code like x[0] = (0xFF / (x[0] + 1)); will also benefit). 2) We can say that currently it's impossible to implement a version of this optimization that is generic enough. 3) We can instead try to fold your optimization into MathFloorOfDiv optimization that reverts (for a limited amount of cases) Math.floor(a/b) into integer division. Honestly I am not sure what to choose. Daniel, what do you think? -- Vyacheslav Egorov On Mon, Jul 30, 2012 at 9:35 PM, <[email protected]> wrote: > > 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() && > I did not realize normal double to integer representation changes are > not truncating. I will add a check for that flag on "change". > > From what I can tell, if the optimization is only applied when the > division has a use count of 1 then marking storing into a typed array as > truncating won't have any effect since "x[0] = 0xFF / (x[0] + 1)" will > always generate a simulate that pushes the division. > > What conditions would be necessary to apply this substitution in that > case? Would it be valid to apply this substitution if there are one or > more simulate instructions for which the division is a use but they > occur after the change instruction (instead of before as in your example > below)? > > https://chromiumcodereview.appspot.com/10825071/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
