Re: no_new_pseudos

[Ian Lance Taylor <iant at google dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jul  8, 2007, Ian Lance Taylor <iant@google.com> 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.

Note that that is exactly what was happening before.  no_new_pseudos
denoted internal state in the middle end.  You are repurposing it from
something bad to something good.

But I believe that repurposing is bad because the backends do not and
should not use no_new_pseudos consistently.  Consistent usage would
require them to check it far more often than they currently do.  That
would be counterproductive and even impossible.  Instead, the backends
only check it for the specific routines which may be called during
register allocation.

Since those are the only backend routines which must check
no_new_pseudos, and those are the only backend routines which do check
no_new_pseudos, I think that trying to reclaim no_new_pseudos as a
generic concept separate from register allocation is inappropriate.


> > 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.

I will do that if there is a general consensus that this is a good
idea.  I personally believe that you are striving for a distinction
which should not exist.  Since we have no reason to believe that the
backend should not create new pseudo-registers before register
allocation, and since we have no reason to believe that after register
allocation starts it will be possible for the backend to create new
pseudo-registers, I believe that you are introducing a layer of
abstraction which does not clarify.

Perhaps a root of the disagreement is that I believe that unnecessary
abstraction is actually harmful.  We are not writing a general purpose
library or API here, for either the middle-end or the backend.  We are
writing a tightly coupled single program.


> > 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.

I was thinking of the middle-end here, not the backend, but I'll
withdraw the comment.  The situation before DF was confusing, but it
was not difficult to handle correctly.


> > 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
> so.

Since that would be obviously nonsensical, it must not be what I
meant.  I must have meant what I said: "it was there to remind people
to call the appropriate functions to resize the register arrays."  I
believe that you are restating the underlying meaning of
no_new_pseudos from what it originally was.

Ian