[LLVMdev] [PATCH] Handle tied sub-operands in AsmMatcherEmitter

[Jakob Stoklund Olesen]

On Apr 23, 2013, at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote:

> There are two core issues. First, the tied operands are an artifact of the way we do instruction selection for the compiler. They’re how we represent read-modify-write operands, basically. The assembler shouldn’t have to know or care about them at all. Specifically, they shouldn’t even be represented at all as an MCOperand. Rather, only the actual operand referenced by the instruction encoding should be an operand, and it should have an instruction-description notation that the operand is RMW. This means that the MI representation and the MCInst representations of the instructions will no longer have a one-to-one operand correspondence, so there will need to be logic to map between them for things like the MC lowering pass (the ill named AsmPrinter), the TargetInstrInfo layer which inherits from MCInstrInfo, and probably others. This is usually, in effect, what many of the ARM assembler aliases of the load/store instructions are doing manually. We just want to automate it.

I would like to add one more case here: Fixed register operands.

Some instructions, like x86's MUL and DIV, take operands in fixed registers. Currently, we handle that with COPY instructions to and from the fixed registers, but that is making code motion passes more complicated than they need to be. (Actually, they usually just run away when they see one of these instructions).

I would like to have MUL32r take two virtual register operands, one of them tied to the fixed register %EAX. Just like two-address instructions, it would be the register allocator's responsibility to satisfy the constraint. This would also make it possible to write proper isel patterns for MUL and DIV.

This doesn't need to happen right away, it is just a second case to consider of MI operands not corresponding directly to encoded MC operands.

/jakob