This is the mail archive of the
mailing list for the GCC project.
On 04 July 2007 18:03, Ian Lance Taylor wrote:
> Richard Sandiford <email@example.com> writes:
>> Ian Lance Taylor <firstname.lastname@example.org> writes:
>>> Richard Sandiford <email@example.com> 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.
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)
Can't think of a witty .sigline today....