This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: no_new_pseudos
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>, Ian Lance Taylor <iant at google dot com>, Kenneth Zadeck <zadeck at naturalbridge dot com>, Alexandre Oliva <aoliva at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, gcc <gcc at gcc dot gnu dot org>, Steven Bosscher <stevenb dot gcc at gmail dot com>, "Bonzini, Paolo" <bonzini at gnu dot org>, richard at codesourcery dot com
- Date: Wed, 04 Jul 2007 14:09:28 -0400
- Subject: Re: no_new_pseudos
- References: <46892386.9080103@naturalbridge.com> <1183392984.3816.1.camel@pc960.cambridge.arm.com> <or7ipi4jwe.fsf@oliva.athome.lsd.ic.unicamp.br> <468ABC2D.8090401@naturalbridge.com> <873b04ilqx.fsf@firetop.home> <m3ir909l6f.fsf@localhost.localdomain> <87lkdwdshp.fsf@firetop.home> <200707041720.l64HKUQ29010@makai.watson.ibm.com> <87ejjodq66.fsf@firetop.home>
Richard Sandiford wrote:
> David Edelsohn <dje@watson.ibm.com> writes:
>
>> I think the proposal is to get the semantics right first and then
>> fix the syntax, not just leave the long, cumbersome flag.
>>
>> Creating a macro or alias could lead to confusion and creates an
>> opportunity for divergence.
>>
>
> I don't understand what you mean by the second sentence. The purpose of
> the macro or alias is precisely to define what the agreed semantics are
> (just as no_new_pseudos does now). My main concern...
>
>From my point of view, my purpose to do this was to get all of the
unnecessary garbage out of the middle end AND TO MAKE SURE EVERYTHING
STILL WORKED!
>
>> Once this initial find-and-replace substitution is done, I am sure
>> that we all will be able to agree on way to rationalize the flags, but we
>> do not need to make all of the changes simultaneously.
>>
>
> ...was that it seems odd to remove an abstraction if we're intending
> to add it back again (and it wasn't clear to me before that we _were_
> intending to add it back again). But if Kenny prefers to do it that
> way -- and is indeed intending to "fix the syntax" -- then that's fine.
>
>
I did the change this way because it is easy to clean up later and i
happen to really dislike derived variables. Over time, these tend to be
misused and redefined because the foo backend just needed it to be a
"little bit" different.
In retrospect, I was perhaps not the best person to do this change
because I do not yet have the experience to look at the backends and
simplify them. I think that ian's point is that had that been done,
(and of course it can still be done), the justification for derived
variables would have been less.
> I liked Dave's suggestion too FWIW.
>
> Richard
>