This is the mail archive of the 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

On 04 July 2007 18:03, Ian Lance Taylor wrote:

> Richard Sandiford <> writes:
>> Ian Lance Taylor <> writes:
>>> Richard Sandiford <> 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)

Can't think of a witty .sigline today....

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