This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: no_new_pseudos
On Jul 5, 2007, Richard Sandiford <rsandifo@nildram.co.uk> wrote:
> Ian Lance Taylor <iant@google.com> writes:
>> I think the best option is for somebody to go through the uses of
>> no_new_pseudos and fix them. Incomplete transitions are bad.
> I admit I'm still not sure on this point, and seeing "fix them" makes me
> even more unsure, so: do you think the targets' tests of no_new_pseudos
> are somehow bad?
Seconded. I don't see that there's anything to fix. What's being
proposed is an incomplete cleanup that, in order to be completed, will
likely require some reverting. This is just silly.
> My point is that I've been using "no_new_pseudos" _in preference to_
> "reload_in_progress || reload_completed" because I find it much more
> mnemonic.
Likewise. That's the property being tested in all cases I remember
having used it. The question is: "Can I create more pseudos at this
point?" If I can, good, I do so. If not, I figure out some other way
to use existing registers to get the same effect, or just fail.
Replacing that with reload_* is actually breaking the required
semantics. Consider that we soon move to a new register allocator,
and we can get rid of reload. It may still use the expanders in some
cases, and it definitely won't want these expanders to introduce new
pseudos. Will it then have to set reload_in_progress just to make the
currently-proposed patch happy? Or go all over the code auditing
every use of reload_in_progress to figure out how it has to be
changed?
Collapsing no_new_pseudos with anything else that doesn't carry the
semantics it currently expresses is a transformation that loses
information. Pretty please don't do this just because the current
code doesn't care about this distinction.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}