151315 2015-11-16 11:08:46 -0800 If B3->Air lowering moves a child to the result tmp when using an Inst with a x86-style UseDef operand, then other uses of that child should also use the result tmp 2015-11-16 12:22:17 -0800 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build All All RESOLVED WORKSFORME P2 Normal --- 151214 1 fpizlo webkit-unassigned oldest_to_newest 1142282 0 fpizlo 2015-11-16 11:08:46 -0800 Consider this: Int32 @2 = Add(@1, @1) Ignoring for a moment the fact that this goes through Shl as a result of reduceStrength(), we will currently do this: tmp mapping: @1 -> %tmp1 @2 -> %tmp2 Move %tmp1, %tmp2 Add32 %tmp1, %tmp2 This prevents us from coalescing %tmp1 and %tmp2, since their live ranges overlap. The solution is that when we decide to emit the result move, we also force a temporary substitution of s/%tmp1/%tmp2/g on the subsequent Inst. This would cause us to do: Move %tmp1, %tmp2 Add32 %tmp2, %tmp2 I believe that such a substitution is both correct and optimal. It's correct because we use arguments before we def them, so although the Add32 def's %tmp2, this happens after all arguments are consumed. Hence, %tmp2 is a correct substitute for %tmp1. It's also optimal, since it avoids the overlapping live range. We have to be somewhat careful about how we implement this. Probably, the temporary substitution will be something that only some lowering rules opt into. 1142293 1 fpizlo 2015-11-16 11:35:11 -0800 LOL, I picked a bad example. We have special-case handling of Shl(x, 1), and Add(x, x) turns into Shl(x, 1). That handling already does the right thing. But this same issue arises for Mul, for example. 1142294 2 fpizlo 2015-11-16 11:47:05 -0800 Hmm! It looks like the register allocator already does magically good things about the Mul case... 1142299 3 fpizlo 2015-11-16 12:21:05 -0800 Whoa, our register allocator already does the magically correct thing. This is Ben's comment: // We do not want the Use() of this move to interfere with the Def(), even if it is live // after the Move. If we were to add the interference edge, it would be impossible to // coalesce the Move even if the two Tmp never interfere anywhere. This is the verbiage in the IRC paper: Move instructions are given special consideration. It is important not to create artifical interferences between the source and destination of a move. Consider the program: t := s ... x := ... s ... ... y := ... t ... ; copy ; use of s ; use of t After the copy instruction both s and t are live, and an interference edge would be added between s and t, since t is being defined at a point where s is live. The solution is to temporarily remove s from the live set and continue.