[llvm-dev] Implicit register move using TableGen

[Craig Topper via llvm-dev]

Here's an example from X86 that reads XMM0. The "let Uses = [XMM0]" adds an
implicit physical register input for XMM0. The outs and ins list the other
virtual register inputs. The pattern uses XMM0 as an operand like the (set
GPR:$rd, (add GPR:$rs1, R14)).

let Uses = [XMM0], Constraints = "$src1 = $dst" in {
  multiclass SS41I_ternary<bits<8> opc, string OpcodeStr, ValueType VT,
                           PatFrag mem_frag, X86MemOperand x86memop,
                           SDNode OpNode, X86FoldableSchedWrite sched> {
    def rr0 : SS48I<opc, MRMSrcReg, (outs VR128:$dst),
                    (ins VR128:$src1, VR128:$src2),
                    !strconcat(OpcodeStr,
                     "\t{%xmm0, $src2, $dst|$dst, $src2, xmm0}"),
                    [(set VR128:$dst,
                      (VT (OpNode XMM0, VR128:$src2, VR128:$src1)))]>,
                    Sched<[sched]>;

    def rm0 : SS48I<opc, MRMSrcMem, (outs VR128:$dst),
                    (ins VR128:$src1, x86memop:$src2),
                    !strconcat(OpcodeStr,
                     "\t{%xmm0, $src2, $dst|$dst, $src2, xmm0}"),
                    [(set VR128:$dst,
                      (OpNode XMM0, (mem_frag addr:$src2), VR128:$src1))]>,
                    Sched<[sched.Folded, sched.ReadAfterFold]>;
  }
}

Here's another more complex example. This one has an input in AL and an
output in AL, EFLAGS, and AH. We listed AX in the implicit defs for both AL
and AH for some reason.

let Defs = [AL,EFLAGS,AX], Uses = [AL] in
def MUL8r  : I<0xF6, MRM4r, (outs),  (ins GR8:$src), "mul{b}\t$src",
               // FIXME: Used for 8-bit mul, ignore result upper 8 bits.
               // This probably ought to be moved to a def : Pat<> if the
               // syntax can be accepted.
               [(set AL, (mul AL, GR8:$src)),
                (implicit EFLAGS)]>, Sched<[WriteIMul8]>;

~Craig


On Sat, Apr 10, 2021 at 2:46 PM Marco Speziali <
marco.speziali at mail.polimi.it> wrote:

> Dear Craig,
> Thanks for the reply. I tried to use the pattern you provided to set
> list<pattern> inside the ADD instruction. Unfortunately the pattern:
>
> (set GPR:$rd, (add GPR:$rs1, R14))
>
>
> Does not generate a move of $rs2 to R14. It, for some reason, produces an
> add with 3 register operands. Which we do not support. The only way to use
> 2 source registers is to move the second one to R14. For example:
>
> add rd, rs1, rs2
>
> Should become:
>
> mv R14, rs2
> add rd, rs1
>
> Is there a way to automate this process using TableGen?
>
> Thanks,
> Marco Speziali
>
> On 10 Apr 2021, at 19:09, Craig Topper <craig.topper at gmail.com> wrote:
>
> In tablegen you can write
>
> (set GPR:$rd, (add GPR:$rs1, R14))
>
> On Sat, Apr 10, 2021 at 9:19 AM Marco Speziali via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Dear all,
>>
>> I need to implement the following behavior for all instructions that
>> require two source operands:
>>
>> %1 = add i16 %a, %b
>>
>> Should match the ADD instruction which has 1 outs and 1 ins. The second
>> operand %b should be moved into the implicit register R14 (fixed).
>> For now I implemented the PseudoADD instruction which gets expanded into
>> a move plus the mentioned ADD instruction.
>> This obviously creates a low of unnecessary moves and prevents any
>> optimizations of the register R14 (e.g. R14 could be used as destination
>> register in previous operations without the need for a move).
>>
>> I'd like to transform the dag:
>>
>> (set GPR:$rd, (add GPR:$rs1, GPR:$rs2))
>>
>> to something like:
>>
>> (set R14, GPR:$rs2), (set GPR:$rd, (add GPR:$rs1))
>>
>> Is it possible to specify this transformation using TableGen? If now how
>> could I achieve this?
>>
>>
>> Thanks.
>>
>> Best Regards,
>> Marco Speziali
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> --
> ~Craig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210410/f727a2eb/attachment.html>