This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]