This is the mail archive of the
mailing list for the GCC project.
- 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: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <468ABC2D.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <200707041720.l64HKUQ29010@makai.watson.ibm.com> <email@example.com>
Richard Sandiford wrote:
> David Edelsohn <firstname.lastname@example.org> 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
>> 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.