When AVR backend generates mulsu instruction ?

Hello LLVMDevs,

I am looking for an example for how to lower LLVM IR to mulsu kind of instruction. I found that AVR back end have such instruction but AVRInstrInfo.td does not define any DAG pattern for which this instruction gets emitted.

def MULSURdRr : FMUL2RdRr<1,
(outs),
(ins GPR8:$lhs, GPR8:$rhs),
“mulsu\t$lhs, $rhs”,
[]>,
Requires<[SupportsMultiplication]>;

Also simple grep around related words does not show any other information.

Can some one explain me how this kind of instruction should be lowered ?

Sincerely,
Vivek

Hey Vivek,

We don’t directly emit the MULSURdRr instruction. On top of this, I don’t believe any of the AVR multiplication instructions have patterns in TableGen.

This is because the AVR mul instructions are quite strange. Almost all of the other instructions of the ‘Rd, Rr’ format take the values of Rd and Rr, perform a computation and place the result in the destination register Rd. The mul instructions implicitly use r0 and r1 to store the results. This makes it quite hard to fit into TableGen and so we perform custom lowering for these nodes.

We expand the MUL DAG node into ‘ISD::UMUL_LOHI’ or ‘ISD::SMUL_LOHI’. We see these in AVRISelDAGToDAG.cpp and custom lower them (see AVRISelDAGToDAG::selectMultiplication) into MULSRdRr or MULRdRr, depending on signedness. Later on we have a custom inserter which inserts instructions to clear the r1,r0 scratch registers after use.

The MULSURdRr instruction you mentioned is not generated by LLVM unless you use it yourself as part of some inline assembly.

Thanks Dylan,

I am working on a backend which has mulhsu instruction that performs multiplication between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction.

-Vivek

Is this code an IR or a machine pass?

If it is IR, you might have trouble checking the signedness of the types because LLVM IR doesn’t make a distinction between unsigned and signed types, and the mul instruction is general enough to be used with either one.

Is this code an IR or a machine pass?

I don't get this question. I am writing a backend for new architecture

target. And I ISelDAGtoDAG.cpp is MachineFunction pass and I think this
pass runs after Legalizing pass. So I should be able to get signedness.
-Vivek

I see, if this is for a new target then you won’t have those problems, the ISel node opcodes have ‘S’ or ‘U’ in the name to indicate sign.