On Monday 28 June 2010 at 00:40, Peter Lobsinger wrote: > Those aren't the temporaries I'm referring to. Many PIR operations > which appear to be single ops compile down to multi-op sequences which > use temporary registers. For example "sqrt $N0, $I0" is internally > "set $N<temp>, $I0 ; sqrt $N0, $N<temp>". As another example, every > function call that IMCC cannot resolve statically uses a > find_sub_not_null and a temporary. It can be almost guaranteed that > any HLL compilation will hit several cases of these IMCC internal > temporaries.
That's right; I'd forgotten about those. I'm almost certain that IMCC's (naive) register allocation takes place after this; I don't know how it would work otherwise. > Does IMCC really have more information than that available in PBC? > What information is present in PIR, isn't present in PBC, and is > relevant to register allocation or optimization in general? It's somewhat easier to detect basic blocks in IMCC's internal structures than in PBC, but that's only relevant if we use some sort of graph coloring algorithm--in the case of an infinite register set, we're better off with linear scan. > By all means, replace IMCC then. But whatever replaces it will also > need to create these temporaries if it is to provide the same kind of > op selection and desugaring to protect the users from lower-level > aspects of Parrot. Full register allocation can only occur after the > selection/desugaring step. Agreed. Register allocation *must* take place after desugaring. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
