This is the mail archive of the gcc@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: Serious performance regression -- some tree optimizer questions


Hello,

> >>>>If you find it helps other testcases, or whatever, i'm happy to try to
> >>>>explore making that patch usable.
> >>>
> >>>OK, the current situation w.r.t. mgrid is as follows:
> >>>
> >>>With unmodified GCC, mgrid on 31-bit generates bad code due to a
> >>>combination of the problem fixed by your patch and IV selection
> >>>issues.  On 64-bit, the problem addressed by your patch doesn't
> >>>occur, but we have problems due to IV sign-extension (and also
> >>>IV selection issues).
> >>
> >>Ivopts is become large.
> >>
> >>As much as ivopts is a nice pass, it really needs to be split up into
> >>strength reduction, iv selection, and the few other things ivopts does now
> >>(and later, addressing mode selection, if he finishes/submits that
> >>patch).
> >
> >why, exactly?  You cannot do this without sacrificing performance of the
> >resulting code -- these optimizations interact with each other.
> 
> Almost all optimizations interact with each other.
> Yet we find a way to keep them separate, and come up with an ordering that 
> doesn't completely sacrifice the performance of the resulting code.
> Sometimes this means we run them multiple times.
> That's just fine.

its just fine when there is not a better way.  Of course we could
iterate dce and cfg cleanup to obtain almost as good code; but it is
simpler to just run cddce.

Similarly, you maybe could run optimizations performed by ivopts
separately, and get decent results (the way it used to be done in
ancient times).  But by taking the optimizations into account at once,
you are able to get better results.

Note that in fact all the optmizations you mention boil down to
selecting a set of bivs that should be used inside the loop.  Once you
know the bivs, you just express each use by the best one of them.
Considering things like strength reduction and iv elimination as
separate optimizations will only make things more complicated.

Note that you of course can ask just for some of the possible
optimizations to be performed.  You do not want strength reduction
of array references?  OK, just tell ivopts that uses inside
ARRAY_REF are just generic iv uses, without telling it that it might
be able to strength reduce them.

> >>There are plenty of things that would benefit from rerunning strength
> >>reduction without rerunning ivopts.
> >
> >Like what?
> 
> Linear loop transforms, vectorization, various other high level loop 
> transforms.

What exactly you mean by strength reduction -- could you please provide
a concrete example?  So far I thought that both Linear loop transforms
and vectorization want loops with a single canonical iv, i.e. the exact
oposite of strength reduction.

> >>I'm not sure why it wasn't a seperate pass in the first place.
> >
> >Well, you can fairly easily ask ivopts to do just strength reduction,
> >if you really want to.
> 
> Really? It's completely non-obvious.

Really.  It seems completely obvious to me :-) Of course, I wrote the
pass.

> >>Also, things like iv selection seem very complex tasks, and as such,
> >>probably deserve their own passes rather than being lumped in with
> >>strength reduction.
> >
> >??? You cannot possibly select right ivs without taking strength
> >reduction and other iv related optimizations into account
> >
> >>They also shouldn't be interfering with passes that
> >>work faster or better with a single canonical iv (which includes linear
> >>loop transforms, and other loop transforms currnetly in progress)
> >
> >They should obviously be performed before ivopts, so there is no
> >interference (ivopts may be easily used for the "single canonical iv" 
> >creation,
> >if needed).
> 
> Without it doing strength reduction (which i don't want to happen till 
> later, since it removes array references and whatnot)?

Yes.  If you need it, I may send you a patch in a few minutes.

Zdenek


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