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 Jul  8, 2007, Ian Lance Taylor <> wrote:

> But since these aspects of the register allocator are not at all
> likely to change, wouldn't it be a waste of time to prepare for them
> now?

Yup.  But from that to concluding that we should remove the clear
abstraction that enables someone to prepare for them right now, that
is useful, mnemonic, clear in meaning, and currently functional.

Replacing that with some variable that denotes some internal state in
the middle end and requiring the back end to use it is exposing the
guts of the middle end to the back end.  That's breaking abstraction
layers.  That's bad software engineering in general.

> I have never liked no_new_pseudos, because it is a negative flag and
> therefore confusing to use.

Oh, if that's all, we can address that.

  s,no_new_pseudos,!new_pseudos_acceptable_p (),g

would address it, without exposing the guts of the middle end to the
back end.

> The former meaning was not as crisp as you would like it to be: it was
> there to remind people to call the appropriate functions to resize the
> register arrays.

That's just another implementation detail of the middle end that back
ends shouldn't have to be concerned with.  Their concern is whether
they can introduce new pseudos or not.  no_new_pseudos provided that
meaning precisely.

> Only it didn't express that very well, so for
> complete correctness you had to actually check both (no_new_pseudos &&
> (reload_in_progress || reload_completed)).

This is news to me.  Why would that be?  Isn't no_new_pseudos always
set when reload_in_progress || reload_completed holds?  If not, then
the proposed change may indeed be harmful to backends.  It seems to be
an indication that the current abstraction is not suitable for all
users.  Replacing it for another abstraction that is not suitable for
all users doesn't seem like a solution, since it merely moves the
problem elsewhere.

> For these reasons, since the underlying meaning of no_new_pseudos is
> no longer necessary,

As in, we can now create new pseudos at any time throughout the
compilation and expect them to be handled correctly?  I don't think

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

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