no_new_pseudos

Alexandre Oliva aoliva@redhat.com
Fri Jul 6 17:46:00 GMT 2007


On Jul  6, 2007, David Edelsohn <dje@watson.ibm.com> wrote:

>>>>>> Alexandre Oliva writes:
Alexandre> Collapsing no_new_pseudos with anything else that doesn't carry the
Alexandre> semantics it currently expresses is a transformation that loses
Alexandre> information.  Pretty please don't do this just because the current
Alexandre> code doesn't care about this distinction.

> 	You repeatedly assert that it loses information, but the
> information is not helpful because there is no distinction.

Right now, there isn't.  But I presented a scenario in which there
could be a distinction.  Are you volunteering to audit the code when
such a scenario comes up?

The point is that this patch removes a useful abstraction, on the
grounds that it can be implemented in terms of other existing
lower-level abstractions.  I don't think this would fly as good
software engineering practice.  It's not just a clean up, it's
squashing a higher-level abstraction into a bunch of lower-level ones.
In my book, that's generally bad practice.  And it's not like there's
even a performance reason to do so.  Quite the opposite.

> This has become a campaign for its own sake.

Indeed, but on which side? ;-P :-D

> So far all I read is complaints from you and Richard, but no
> offers to implement your more extensive proposal in the next few weeks.

That's because there is no need to implement any extensive proposal.
If the abstraction is retained (e.g. by means of a macro), and it
remains used correctly, nothing whatsoever is lost.

I'm yet to see any reason to *remove* this abstraction, and to
understand what these "needed fixes" are.

> You simply are making demands that volunteers implement more extensive
> transformation.

Quite the opposite, actually.  I'm making suggestions that not only
reduce the extent of the proposed patch (that was already rejected on
other grounds), but also reduce the impact on other volunteers now and
in the future, because of the need for their using lower-level
abstractions *and* an eventual need for re-auditing the same change
for no gain whatsoever.

> This is a giant Bike Shed preventing incremental improvement in GCC.

On what grounds do you consider removing the abstraction an
improvement?

I agree that removing the variable right now is a good thing.

It's only the removal of the abstraction, by replacing it by a
combination of other lower-level abstractions, that I object to.

> The proposed patch is not wrong.

Indeed.  It's not wrong.  It just creates needless work for others,
now and in the future, which could be easily avoided.

> Arguing about it and trying to block it serves no useful purpose.

It was already rejected because of incorrect application of the
transformation.  This is yet another indication that the way it was
implemented was risky and potentially harmful.  Now, which is easier,
re-review every one of the transformations to make sure it was done
correctly, or retain the existing abstraction and drop the needless
changes to accommodate its removal?

-- 
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}



More information about the Gcc mailing list