[llvm-dev] Implicit register move using TableGen

Marco Speziali via llvm-dev llvm-dev at lists.llvm.org
Sun Apr 11 08:55:36 PDT 2021


Dear Craig,
I have an other small question if possibile. In my case also branches and stores follows the same rule (second source register must be moved into W).

I have this pattern:

def : Pat<
  (brcond GPR:$cond, bb:$imm),
  (PseudoBNE GPR:$cond, 0, imm16bb:$imm)
>;

Used for brcond without sect (i.e. condition calculated elsewhere). I’d like to remove the PseudoBNE and use BNE (with a single source register). But I cannot figure out how to tell TableGen that 0 must be moved into R14.
Other patterns I need to convert are:

def : Pat<
  (truncstorei8 GPR:$src, (i16 (isabella_wrapper tglobaladdr:$dst))),
  (PseudoSB GPR:$src, R0, tglobaladdr:$dst)
>;
def : Pat<
  (store GPR:$src, (i16 (isabella_wrapper tglobaladdr:$dst))),
  (PseudoSW GPR:$src, R0, tglobaladdr:$dst)
>;

R0 is a constant register = 0.

The 3 patterns have in common the fact that zero must be moved into R14.

For the first pattern (PseudoBNE): is it possibile to transform the dag from

(brcond GPR:$cond, bb:$imm)

to:

(brcond (i16 (setne GPR:$cond, 0)), bb:$imm) ?

In that way the BNE instruction would be selected automatically. The same for the other two, I’d just need to convert:

(store GPR:$src, (i16 (isabella_wrapper tglobaladdr:$dst)))

to:

(store GPR:$src, (add 0, (i16 (isabella_wrapper tglobaladdr:$dst)))

I also tried to do:

def : Pattern<
  (brcond GPR:$cond, bb:$imm),
  [
    (set R14, 0),
    (BNE GPR:$cond, imm16bb:$imm)
  ]
>;

Unfortunately since R14 is not directly used by BNE, TableGen complains about temporaries not supported.

Thanks for all the help.

Marco Speziali

On 11 Apr 2021, at 12:31, Marco Speziali <marco.speziali at mail.polimi.it<mailto:marco.speziali at mail.polimi.it>> wrote:

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/268a4f43/attachment-0001.html>


More information about the llvm-dev mailing list