Vladimir Makarov wrote:
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of an alternative will often restrict the
register classes available for each of the operands. Presumably we'd
want to encode that information it the conflict graph so that IRA
would allocate registers so as to fit the constraints of the early
insn alternative selection. Right? In the case where the graph is
uncolorable, do we allow IRA to override the alternative selection,
or do we insert copies to simplify the conflict graph or some mixture
of both?
Thoughts?
As for copies, I think it would be a bad decision to stick only to
original (after the code selection) alternative and generate copies to
satisfy this alternative. For example, if pseudo got memory instead
of hard-register required by the alternative, it would be bad to
generate a copy (ld/st in this case) if memory is accepted by the insn.
That's why I mentioned the possibility of relaxing the conflict graph to
allow other alternatives if we find that the graph is uncolorable. So
if we initially wanted class A, but couldn't get it and the operand
could accept class B, then we remove the conflict between the pseudo and
the hard regs in class B and recolor.
I have no idea how expensive this would be.
This also implies that we're representing conflicts for register classes
& memory in the conflict graph.
Jeff
