Adding MachineOperands that are not part of MCInstrDesc.

Hi,

I wonder if it is okay to add an operand that is not part of MCInstrDesc to an MI after isel?

There are things going on like instruction combining, rematerialization etc, which may call MI with TI->get(opcode). If an MI would get replaced with a new instance of itself in this way, any previously added operands would get lost, as they are not part of the MCInstrDesc.

RegAlloc, does this, so I assume it is safe to add operands post-ra. I wonder if it also safe to add phys-reg defs/uses directly after DAG isel? Would it be a bug if they would be removed by a transformation?

Thanks,

Jonas Paulsson

Hi,

I wonder if it is okay to add an operand that is not part of
MCInstrDesc to an MI after isel?

There are things going on like instruction combining,
rematerialization etc, which may call MI with TI->get(opcode). If an
MI would get replaced with a new instance of itself in this way, any
previously added operands would get lost, as they are not part of
the MCInstrDesc.

RegAlloc, does this, so I assume it is safe to add operands post-ra.
I wonder if it also safe to add phys-reg defs/uses directly after
DAG isel? Would it be a bug if they would be removed by a
transformation?

You can add implicit uses and defs. You may get lucky and adding explicit defs
and uses will work, but I would not recommend doing this. If you really need
to do this, you could make the instruction variadic or create two instruction defs,
one with n operands and one with n + 1.

-Tom

Hi,

So what about post-ra - is it safe there?

thanks,

Jonas

Hi,

So what about post-ra - is it safe there?

If you run the MachineVerfier post-ra it will fail. For other passes,
it may be safe now, but there's no guarantee it will be safe in the
future.

-Tom