This is the mail archive of the 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]

Re: Higher level RTL issues

On Monday, October 22, 2001, at 12:34  PM, wrote:

>   In message <>you 
> write:
>> <snip the rest, for various reasons, i'm not going to reply>
>>> I'll have to show you an example where you do need renaming to perform
>>> relatively simple redundancy elimination problems that are found by 
>>> any
>>> reasonable value numbering scheme.
>> Please, do.
> I'm going to try to get it to y'all today.
Okey dokey.
 From the thread, bob morgan says: " However, other
transformations, such as eliminating copy operations, can cause two
variants of the same register to be live at the same time. In that
case the easy thing to do is to actually rename the registers as new
I'll take his word for it.
However, note that he says the "easy" thing.
He doesn't say it's impossible.
*If*  two variants of the same register became live at the same time, 
It's a matter of updating definitions in the case of FUD chains, while 
you usually can get away with doing nothing in explicitly renamed ssa 
Of course, what *we* should do, if we only had to select one thing,  (in 
terms of renaming or fud chains) depends on which type of problem we 
have more, forwards or backwards.
I'd rather *allow* us to do both.
If part of the point of the SSA path is to be fast and efficient, and 
cut down the amount of rtl we have to deal with in later, slower, 
passes, then what makes most sense is something like:

Convert to FUD chains
SSA-CCP (including simple dead-code removal)
Aggressive DCE
<other ssa optimizations that are faster or easier on fud chains>
Convert to explict renamed form
<Other SSA optimizations that are faster or easier with renaming>

This is because fud-chains are going to be faster to work with for 
things that remove a lot of code quickly. For instance, while SSA-CCP on 
explicit renamed form will require up to two evaluations per operand of 
an operation, on fud-chains, you can guarantee to evaluate each thing 
only once.

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