[llvm-dev] Implicit register move using TableGen

Marco Speziali via llvm-dev llvm-dev at lists.llvm.org
Sun Apr 11 03:31:09 PDT 2021


Dear Craig,
it now works as intended.

Thank you so much,
Marco Speziali


On 11 Apr 2021, at 00:06, Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>> wrote:

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<mailto: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<mailto: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<mailto: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<mailto: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/20210411/91864218/attachment-0001.html>


More information about the llvm-dev mailing list