On Jul 6, 2007, David Edelsohn <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
