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.
Jeff
