Hi, On Thu, 30 Nov 2017, Jeff Law wrote:
> And after PHI propagation we have: > # m_5 = PHI <10(5), 12(6), 14(7)> > # _2 = PHI <10(5), 12(6), 14(7)> > # _3 = PHI <320(5), 384(6), 448(7)> > <L13>: > goto <bb 12>; [100.00%] > > DCE will come along and wipe out m_5 and _2 if they are unused. When I did something along these lines a long time ago I had to be a bit careful in not regressing performance. Every PHI node with constants will generate N instructions (with N the arity), there's no coalescing possible. And if the feeding PHI nodes don't go away it increases register pressure by (at least) one. In one situation at that time I basically replaced N PHI nodes and N*N instructions (each calculating x op y for each x,y \in PHI) by N*N PHI nodes, increasing register pressure unsensibly. As the N*N instructions formed a few expr trees the register pressure before the transformation was merely at about N+3. In the end the benchmark was 30% slower than faster :) (spilling added) (If I read the patch correctly you don't handle the situation of "x op y" where both arguments come from PHI nodes, so it's probably not an issue for you, but I thought I'd mention it) Ciao, Michael.
