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]: Improve ability of PRE to detect redundancies


On Tue, 2004-11-30 at 17:40 +0100, Zdenek Dvorak wrote:
> Hello,
> 
> > > I would expect whatever is doing rematerialization would determine
> > > whether it wants to undo that or not :).
> > > 
> > 
> > A solution for avoiding this "do/undo game" is to help PRE to decide
> > in which case to transform or not, based on accurate information.
> > You're clearly missing the information about the register pressure.
> > Would it be possible to have an analyzer at the PRE level, that
> > approximates the number of registers needed for a given loop?
> 
> restricting the PRE in this way would be great (not really because of
> these corner case problems, but since the increased register pressure
> due to PRE seems to be a serious problem just now).

Except on x86, PRE's register pressure increases aren't doing noticeable
harm
I've spec'd PPC with -fno-tree-pre and it causes a couple percent
*degradation* in both SpecINT and SpecFP.  

On x86, you just need a much better register allocator, regardless of
how much you restrict PRE.

> 
> The problem is (IMHO -- not really expert in the area) that doing it and
> not limiting PRE too much is hard.

Yes.
Becuase it requires knowing what's going to happen in the future, and
what the register allocator will do.

> 
> Postponing this for rematerialization also is not somehow great solution,
> since doing rematerialization properly is about as complicated as PRE
> itself.

This is, unfortnuately, the only real solution.  We know that we will
have register pressure problems until our register allocator is at the
same level as our optimizations have started to become.  It's clearly
not there.

>   So what you end up with is a half-heuristic solution that
> handles some common cases, but very often fails.
> 

Which is not something we should strive to do :).

> Zdenek


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