On Wed, 29 Aug 2018, Jeff Law wrote: > On 08/29/2018 04:56 AM, Richard Biener wrote: > > > > In response to PR87105 I dusted off an old patch that adds an early > > phiopt pass. Recognizing we run phiopt twice with not many passes > > in between early in post-IPA optimizations this patch moves the > > first of said to the early pipeline. > > > > The main motivation is to do things like MIN/MAX_EXPR early to > > avoid jump threading mess up the CFG (the case with PR87105). > > I realize theres early backward threading before the new early > > phiopt pass but that doesn't seem to do anything useful there (yet). > > I think it makes sense to push that later anyways. > > > > Now, early phiopt is quite confused about predict stmts still > > being present and turning conditional BBs into diamonds which it > > cannot handle. I've fixed at least stray such stmts in the BBs > > that are interesting. Note this may hide fallout which would otherwise > > be visible in the testsuite (there's no flag to avoid > > generating the predictors - they are emitted directly by the frontends, > > maybe we could drop them with -fno[-guess]-branch-probabilities at > > gimplification time?). > > > > There's also an effect on ifcombine which, when preceeded by phiopt, > > can miss cases because phiopt may value-replace some condition. > > > > The patch contains adjustments to testcases where there's no harm done > > in the end and leaves those FAILing where we would need to do sth. > > > > In the end it's regular pass-ordering issues but our testsuite very > > often ties our hands when re-ordering passes because of them. > > > > One option would be to distinguish early from late phiopt and for > > example avoid value-replacement - like just do MIN/MAX recognition > > for the vectorizer. > > > > Any comments? > > > > Some detailed notes on the remaining FAILs below. > [ ... ] > I didn't see anything in the testsuite fallout that gave me significant > concern. If your judgment is that we're better off running it earlier, > then let's do it.
I guess so. I'll add an early variant anyway since we don't want to do adjacent load hoisting early. I'll see how difficult it is to handle ifcombine merging with straight-line code or catch those cases elsewhere. Richard.
