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. > 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 so. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
