On 04 July 2007 18:03, Ian Lance Taylor wrote:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>
>> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>>> Richard Sandiford <[EMAIL PROTECTED]> writes:
>>>> 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?
>>>
>>> I would prefer to get rid of it and clean up afterward.
>>
>> So which of (1) and (2) from my message do think is best? Replace backend
>> uses with "reload_completed" when doing so is safe, or consistently replace
>> it with "reload_in_progress || reload_completed" throughout the backends?
>
> The latter, followed by a cleanup. In many cases it can simply drop
> out. In the current framework, the only cases where it needs to be
> checked are in the move expanders.
>
> That said, I would not object to a new global variable,
> before_regalloc or may_create_pseudos or something like that, meaning
> that it is OK to freely create new pseudo-registers. I don't like
> no_new_pseudos because it is a negative flag and because of the
> historical baggage that it carries.
Fair enough.
Since it is still a derivative condition that depends solely on the
before/during reload status, maybe it would be cleanest to make a predicate
macro for it?
#define MAY_CREATE_NEW_PSEUDOS_P (!reload_in_progress && !reload_completed)
... if I wanted to write /really/ self-documenting to the point of excess
code, I'd probably even consider phrasing it as ...
#define BEFORE_RELOAD_P (!reload_in_progress && !reload_completed)
#define MAY_CREATE_NEW_PSEUDOS_P (BEFORE_RELOAD_P)
cheers,
DaveK
--
Can't think of a witty .sigline today....
