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


> Now, it is true that the overspecification of the comment above its
> declaration may have led people to use it for different purposes.
> While some may have used it to test whether new pseudos can be
> created, others may have used it to test whether we're on or past life
> analysis.  Whether these will break as we relax the restrictions on
> creation of new pseudos is something that only auditing and testing
> will tell.  This is a negative side effect of abstraction overloading.

I see it as an effect of NOT creating an abstraction or, perhaps more
precisely, creating a BAD abstraction.

What the expanders need to know is "can I create a pseudo now?".  This does
translate into a "state of compilation" but that's not the needed
abstraction.  What's happened is both that parts of the compiler have used
no_new_pseudos for both its original purpose and as a "state of
compilation" flag and that other parts have used things that are explicitly
a state (e.g., "reload_completed") as a test for whether it's safe to
create new psuedos.  This has produced the current mess.

I think it's simpler if we have some way of answering each question that
some code needs an answer to.  If an expanded needs to know "I don't care
where we are in the compilation process, I just need to know if I can
create a pseudo", there should be a way to answer that question.  If, for
some reason, there's a direct need to know "are we currently in reload",
there should be a way to determine that.  But when we start trying to use
the same test to answer both questions, I feel we'll get into trouble.


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