Ian Lance Taylor wrote: > Alexandre Oliva <[EMAIL PROTECTED]> 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. > >
To be even more blunt, I never viewed no_new_pseudos as a useful abstraction It was a gate that protected a set of badly designed concrete datastructures. Those datastructures are gone, and since I (perhaps even we) never viewed it as being an abstraction, I (we) are confused at the discussion of what to replace the "abstraction" with. I am a middle-end person with only cursory knowledge of the backends. >From the middle end's point of view, casting the pseudos in terms of reload/register allocation is in fact exactly the right abstraction. Before register allocation, you have an infinite number of registers and after register allocation, you only have what the machine provides. No_new_psuedos was there to put an extra layer there because of a set of unfortunate datastructure decisions, but the proper interface for the backends is that they can behave in a manner where they have in infinite number or registers before register allocation and only the fixed registers after register allocation. I would very much like ian to put in his patch and i will redo my patch for the middle end and lets move on. kenny > 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 >
