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