[llvm-dev] tablegen dag syntax question

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 26 16:56:26 PDT 2019

A specific register shouldn't be in the "outs" list. outs is for registers
the register allocator has freedom over. The GPR in RISCV tells the
register allocator what register class to pick registers from. It's also
used to tell the autogenerated assembly parser what type of operand it
should be looking for when parsing. The $rd will also be mentioned in an
assembly string to know where it goes relative to other operands.

If you instruction always write to a specific register this is what we call
an implicit definition. It should be listed as "let Defs=[R2] in" before
the instruction definition. There's a simpler Uses for implicit uses.


On Fri, Apr 26, 2019 at 4:39 PM Chris Sears via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> What is the difference between these two fragments (taken from two
> different tblgen record dumps)?
>   dag OutOperandList = (outs GPR:$rd);
>   dag OutOperandList = (outs R2);
> The first is from the RISCV backend record dump. There will be a
> substitution at some point for $rd. In the second, I'm specifying R2, no
> substitution necessary.
> If I specify GPR64:R2 or i64:R2 in my Instruction def, rather than just
> R2, tblgen complains:
>   error: expected variable name in dag literal
> If I use R1000 (which isn't defined) I get what I'd expect:
>   error: Variable not defined: 'R1000'
> There isn't any documentation (that I could find) for this syntax.
> Consequently, I'm a little worried that using R2 rather than something:R2
> is somehow wrong.
> Why does the RISCV dag use GPR:$rd rather than just $rd?
> C
> _______________________________________________
> 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/20190426/c8863b9e/attachment.html>

More information about the llvm-dev mailing list