Re: no_new_pseudos

[Richard Sandiford <richard at codesourcery dot com>]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> Alexandre Oliva wrote:
>> On Jul  2, 2007, Richard Earnshaw <Richard.Earnshaw@arm.com> wrote:
>>
>>   
>>> On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
>>>     
>>>> I do not remember if it was stevenb or bonzini that observed that
>>>> because of changes that came with the dataflow branch it is now trivial
>>>> to get rid of no_new_pseudos.  All of the sets can just go away, as well
>>>> as the tests of it that occur in passes that only run before reload.
>>>>
>>>> For those few passes that can run both before and after reload, the test
>>>> would be replaced with a test of reload_completed.
>>>>
>>>> I believe that the original purpose of this was to protect certain
>>>> datastructures that had to be resized manually when pseudos were added. 
>>>> However, all of these are gone, and have been replaced with structures
>>>> inside of df that are automatically resized.
>>>>
>>>> Does anyone think this is a bad idea?  A grep for no_new_pseudos bears
>>>> out that nothing is really going on here anymore. 
>>>>       
>>
>>   
>>> There are 199 uses of it in the backends; compared to 32 in the front
>>> end.
>>>     
>>
>>   
>>> So it is quite heavily used by MD code.
>>>     
>>
>> I recall having used it a number of times in expanders that shouldn't
>> create new pseudos during reload.  These could easily be turned into
>> (reload_in_progress || reload_completed).  Maybe we could turn
>> no_new_pseudos into a macro that expands to this?
>>
>>   
> 199 reasons not to create pseudos. 

What about the earlier idea of keeping no_new_pseudos and making it
equivalent to "reload_in_progress || reload_completed", either by being
a macro or by being a variable?  The alternatives seem to be:

  1. Test reload_in_progress || reload_completed only where necessary.
     Use reload_completed only if possible.

  2. Replace all uses of "no_new_pseudos" with "reload_in_progress
     || reload_completed"

(1) seems error-prone: what if one of the target's utility functions
was originally only used before and after reload, but later becomes
useful during reload too?  The function will already be geared for
the "no new pseudos" case, and it would be easy to forget to add
reload_in_progress.

(2) doesn't really seem like progress; the new condition is longer
and seems less mnemonic to me.  Most backend code conditional on
no_new_pseudos really is asking "can I create a pseudo now?"

Richard