Let me try to answer some of this... On Tue, May 07, 2019 at 03:31:27PM +0200, Richard Biener wrote: > On Mon, 6 May 2019, Jiufu Guo wrote: > > This patch implements the optimization in PR77820. The optimization > > eliminates phi and phi's basic block, if the phi is used only by > > condition branch, and the phi's incoming value in the result of a > > CMP result.
> I'm not sure I like a new pass here ;) The transform is basically > tail-duplicating the PHI block because the exit conditional can > be "simplfied" - that's something jump threading generally does > though it relies on "simplified" being a little bit more simplified > than above. Right, but where in the pipeline does this fit in? > I suspect this transform was implemented because of some benchmark? Something in SPEC... 2006 iirc... Will need to dig it up, I forgot the details. > I suspect the performance benefit is because of better branch > prediction by not mangling both conditional branches into one? No, it is that previously a condition was moved to a GPR, and then compared again. See PR77820. This is expensive, and serial, too. > The transform is also somewhat similar to tail-duplication done > in path splitting or tracer. Yes. > The pass itself does quite strict pattern-matching but I wonder > if more cases should be handled this way. Maybe. Probably. But which? > Any specific reason for the pass placement between PRE and sinking? > tracer and path splitting run much later, jump threading runs > all over the place. Dunno. Jiufu, does the pass placement matter much? Segher
