Dropping of old loop optimizer
Daniel Berlin
dberlin@dberlin.org
Fri Feb 28 21:56:00 GMT 2003
On Friday, February 28, 2003, at 09:29 AM, law@redhat.com wrote:
> In message <20030228095445.GD5431@kam.mff.cuni.cz>, Jan Hubicka writes:
>>>
>>> On Thursday, February 27, 2003, at 12:13 PM, Pop Sébastian wrote:
>>>
>>>> On Thu, Feb 27, 2003 at 05:39:17PM +0100, Zdenek Dvorak wrote:
>>>>>
>>>>> The problem I see is that rtl ssa is broken (or never worked?); but
>>>> Last time I had a close look at rtl was about two years ago :-)
>>>> Dan is the expert to ask about the status of SSA at rtl level (he
>>>> adapted
>>>> the CCP code from rtl to tree-ssa).
>>> The problem with RTL SSA is hard registers and subregs.
>>> There are hard registers assigned in certain cases during initial RTL
>>> generation.
>>> These can't be renamed, obviously.
>>
>> The tree-SSA represents the SSA form as datastructure on the top of
>> the
>> trees not modifying the trees themselves, right? Why it is not
>> feasible
>> for RTL (ie you won't need to rename the registers)
> hard-regs and subregs really aren't really the problem with rtl-ssa,
> they're both solvable.
however, last i looked, your solution was going to be to just not do an
ssa path when subregs existed
And if they were all that easy to solve, we would be doing register
allocation on an SSA form, like every other compiler in existence.
> The first by ignoring them, the second with
> some annoying, but not terribly difficult work in the ssa->normal
> translator.
Both of which suck, to be honest, and *are* difficult enough that
nobody has *done* it yet.
>
> What is far more of a problem for rtl-ssa is the lack of any kind of
> generic level rtl.
>
With what properties, exactly?
> The tree-SSA branch using a rewriting SSA form now.
>
> Jeff
>
More information about the Gcc
mailing list