|
From: Julian S. <js...@ac...> - 2012-02-07 11:32:55
|
> Consider this: > > PUT(0) = 0xF:I64 > t1 = GET:I64(0) > PUT(4) = 0x1E:I32 > t2 = GET:I64(0) > t3 = And64(t2,t1) > > sameIRExpr(t2,t1) will return true. But the computed values are > different. Salvaging this will be more difficult, as guest state access > is not in SSA. Yeah, you have a partial overlap on the Puts and Gets. I'd suggest that you limit sameIRExpr to recursing only over Un/Bin/Tri/QuadOps, constants and IRTemps, and simply give up on anything else. That will solve the original false positive problem and should be safe for the example above, since it will never conclude that two Gets produce the same value. Similarly it avoids us having to deal with complexities of equal-value proofs in the presence of loads, stores and dirty helpers. IR transformation passes that happen before constant folding include Put-to-Get forwarding (that handles the above overlap cases safely), so such a limitation for sameIRExpr is not as bad as it might at first sound. Come to think of it, iropt also contains a CSE pass (completely unrelated to the constant folder) which must also deal with this same equivalance-detection problem. You might like to have a look at it. I'm sure it uses the same give-up-if-we're-not-sure hac^H^H^Hstrategy. It would also possibly have solved this entire problem a different way (if we CSEd before folding) but is mostly not used, because it is expensive. If you want even more fun IR optimisation hacking you could rewrite it to be much faster :-) J |