This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH/RFC] Simplify wrapped RTL op
On Tue, Aug 27, 2019 at 05:09:52AM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2019 at 11:12:32AM +0200, Robin Dapp wrote:
> > as announced in the wrapped-binop gimple patch mail, on s390 we still
> > emit odd code in front of loops:
> > aghi %r1,-8
> > srlg %r1,%r1,3
> > aghi %r1,1
> This is done like this because %r1 might be 0.
> We see this same problem on Power; there are quite a few PRs about it.
> [ ... ]
> > helps immediately, yet overflow/range information is not considered.
> Yeah, and it has to be.
> > Do
> > we somehow guarantee that the niter-related we created until doloop do
> > not overflow? I did not note something when looking through the code.
> > Granted, the simplification seems oddly specific and is probably not
> > useful for a wide range of targets and situations.
> You're at least the third target, and it's pretty annoying, and it tends
> to cost more than two insns (because things can often be simplified
> further after this). It won't do super much for execution time, there
> is a loop after this after all, a handful of insns executed once can't
> be all that expensive relatively.
> > Another approach would be to store "niter+1" (== n) when niter (== n-1)
> > is calculated and, when we need to do the increment, use the niter+1
> > that we already have without needing to simplify (n - 8) >> 3 + 1.
> > Any comments on this?
> > The patch above bootstraps and test suite is without regressions on s390
> > fwiw.
> When something similar was tried before there were regressions for
> rs6000. I'll find the PR later.
PR37451. Not clear what target that regressed on, btw.
> I was hoping that now that ivopts learns about doloops, this can be
> handled better as well. Ideally the doloop pass can move closer to
> expand, and do much less analysis and work, all the heavy lifting has
> been done already.