This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Early phiopt pass
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.