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: CSE optimization question


>     Long term all the CSE path following cap should be zapped.  It's horrible
>     code with dreadful compile-time performance characteristics.  We can get
>     the same optimizations (in fact more optimizations) by doing value
>     numbering on expressions as we convert into SSA -- the cost for doing this
>     during the translation into SSA is unmeasurable.
> 
> I asked this before, but why isn't GCSE making that obsolete now? It isn't,
> but I don't understand *why* it isn't.
Basically I believe that
1) GCSE does not local CSE, just inter-block one (I may be mistaken here)
2) GCSE is noop on hard registers and other side cases CSE handles
3) CSE do cost based decisions and it is able to do much more simplification
   in fold_rtx than GCSE that simplifies only in CPROP pass and not that well.

Main problem I see is that our CSE is not just CSE, it does whole buch of
related stuff - arithmetic simplification, register height reduction, 
rematerization of cheap expressions (reverse CSE), critical path reduction
in some cases and most of them not very well, but still better than nothing.

I think resonable way is to create branch and try to replace these features
on-by-one by proper passes. THese passes can even get to the mainlne before
CSE is obsoletted because they are benfical anyway.

We've done that for jump pass that was not shorter and on the cfg branch
we are hoping to do the same for loop optimizer.

Honza


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