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


Richard Kenner wrote:
>> 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.
>   
just as a small point, at least the ppc does behave differently with my
patch then without it.  Apparently there areplaces, at least in the ppc
backend that did not generate pseudos before reload because of the
abstraction that are now able to generate them.

I did not do any measurements to see if this effected the generated code
in a material way, only that more pseudos were generated. 

kenny


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