On Jul 5, 2007, Richard Sandiford <[EMAIL PROTECTED]> wrote: > Ian Lance Taylor <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}