[llvm-dev] BPF tablegen+codegen question (original) (raw)

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Tue May 12 14:30:45 PDT 2020


I believe that's done by the " let Constraints = "$dst = $src2" " here

let Constraints = "$dst = $src2" in { let isAsCheapAsAMove = 1 in { defm ADD : ALU<BPF_ADD, "+=", add>; defm SUB : ALU<BPF_SUB, "-=", sub>; defm OR : ALU<BPF_OR, "|=", or>; defm AND : ALU<BPF_AND, "&=", and>; defm SLL : ALU<BPF_LSH, "<<=", shl>; defm SRL : ALU<BPF_RSH, ">>=", srl>; defm XOR : ALU<BPF_XOR, "^=", xor>; defm SRA : ALU<BPF_ARSH, "s>>=", sra>; } defm MUL : ALU<BPF_MUL, "*=", mul>; defm DIV : ALU<BPF_DIV, "/=", udiv>; }

As to your second question. I think the register class is only consulted by tablegen to find the type. It's not used to constrain the register class. That's done by the ins/outs of the instruction. So there's probably not difference between GR64 or i64 in this case.

~Craig

On Tue, May 12, 2020 at 2:23 PM Chris Sears via llvm-dev < llvm-dev at lists.llvm.org> wrote:

In BPF, an ADD instruction is defined as a 2 register instruction:

0x0f. add dst, src. dst += src In BPFInstrInfo.td this kind of ALU instruction is defined with: def rr : ALURR<BPFALU64, Opc,_ _(outs GPR:$dst),_ _(ins GPR:$src2, GPR:$src),_ _"$dst "#OpcodeStr#" $src",_ _[(set GPR:$dst, (OpNode i64:$src2, i64:$src))]>; How does tablegen+codegen ensure that dst and src2 are the same register? I see that the assembly/disassembly string assumes this is the case. Also, it uses i64:$src which is an i64 and not a GPR. What is the distinction there? X86 does this differently. src1 and src2 are GR64 registers. def IMUL64rr : RI<0xAF, MRMSrcReg, (outs GR64:$dst),_ _(ins GR64:$src1, GR64:$src2),_ _"imul{q}\t{$src2, dst∣dst|dstdst, $src2}", [(set GR64:$dst, EFLAGS, (X86smulflag GR64:$src1, GR64:$src2))]>, Sched<[WriteIMul64Reg]>, TB; Chris


LLVM Developers mailing list llvm-dev at lists.llvm.org https://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/20200512/af8ba1ad/attachment-0001.html>



More information about the llvm-dev mailing list