Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Jul 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> 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
