This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: no_new_pseudos


Ian Lance Taylor <iant@google.com> writes:
> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Jul  5, 2007, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>> 
>> > The work here is not changing the bits.  the work here is the actual
>> > auditing of each place to see if it was the correct place.
>> 
>> Then I guess the best option is to leave no_new_pseudos defined as a
>> macro, such that we can introduce the enumeration and migrate to it in
>> a way that makes it clear what has been migrated and what hasn't.
>
> 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?  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.  I certainly haven't been using it because the
code had to handle "no_new_pseudos && !reload_in_progress &&
!reload_completed".

That's why it seems so odd to me to want to get rid of the port uses
and not replace it with something directly equivalent.  I just don't
see how it qualifies as a clean-up.  I think tying the ports even
more to reload-specific conditions, even when we already have a more
abstract concept, is the wrong way to go.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]