This is the mail archive of the gcc@gcc.gnu.org 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


Alexandre Oliva <aoliva@redhat.com> writes:

> See why imprecise abstractions are a problem, and why lowering
> abstractions just because it's possible ATM, without any performance
> or maintainability gains to justify them, is a losing proposition in
> the long run?

To be blunt: no, I don't.  I see a set of hypothetical possibilities,
none of which I consider to be at all likely.

Any decision can be argued endlessly.  That's why this is a bikeshed.
Two patches have been proposed.  For a bikeshed, real code wins over
abstract discussion.

More specifically, backend routines are never called arbitrarily or
randomly.  The backends already know that only the insns which have to
check no_new_pseudos are the move expanders and the splitters.  For
example, look for calls to gen_reg_rtx in i386.md.  Most of them do
not check no_new_pseudos, and they don't have to.  If you want your
more general semantics, don't you logically have to change that too?
After all, just as the register allocator might somehow support
creating new pseudo registers in the middle of it, the register
allocator might similarly support changing the operations which were
done.  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?

I have never liked no_new_pseudos, because it is a negative flag and
therefore confusing to use.  It is also currently carries no meaning.
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.  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)).  Only nobody bothered to do
that, because passes generally knew whether they were run before or
after register allocation.  Note that because of this the backend
routines treated the variable differently from the frontend routines.
For these reasons, since the underlying meaning of no_new_pseudos is
no longer necessary, I am seizing the opportunity to eliminate it.

Ian


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