[llvm-dev] When AVR backend generates mulsu instruction ?

[Dylan McKay via llvm-dev]

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.

On Mon, Feb 27, 2017 at 12:41 AM, vivek pandya via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170227/9f435a10/attachment.html>