On 12/04/2017 02:25 PM, Michael Matz wrote: > 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. Yup. I ran into similar problems with a different patch in this general space. It's actually fairly easy to restrict to single use cases if we wanted which should result in never making things worse at the expense of sometimes not making it better when it could.
> > (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) True, I don't handle x op y where both come from PHIs. It's just X OP CONST where X comes from a PHI with all constant arguments. jeff ps. Ironically I was wandering through the regression list yesterday and stumbled on a BZ which *may* be helped by this code. I still need to dig deeper though.
