[llvm-dev] dumb question about tblgen

Wed May 25 22:45:02 PDT 2016

There is a comment in MachineValueTypes.h in the enum.

      // If you change this numbering, you must change the values in
      // ValueTypes.td as well!
      Other          =   0,   // This is a non-standard value

I don't think the .td include can be fixed easily. Tablegen doesn't support
include guards and can only include each file once. Looks like there is a
build step that runs tablegen directly on Intrinsics.td so that file needs
to include ValueTypes.td on its own.

On Wed, May 25, 2016 at 10:20 PM, Lawrence, Peter <c_plawre at qca.qualcomm.com
> wrote:

> Craig,
>
>            Ahha, thanks.
>
>
>
> Even with that info I had to resort to “find-grep” to figure out how it
> gets #included,
>
> Being indirectly included from “include/llvm/IR/Intrinsics.td” isn’t
> exactly obvious :=((
>
>
>
> Would it be possible move the #include into “Target.td” ?
>
>
>
> Also, in “ValueTypes.td” there is a comment about needing to keep it
> coordinated
>
> With “MahineValueType.h”,  but there is no such comment in
> “MachineValueType.h”,
>
>
>
> Would it be possible for someone to add such a complementary comment ?
>
>
>
>
>
> Thanks,
>
> --Peter Lawrence.
>
>
>
>
>
>
>
> *From:* Craig Topper [mailto:craig.topper at gmail.com]
> *Sent:* Wednesday, May 25, 2016 9:31 PM
> *To:* Marcello Maggioni <mmaggioni at apple.com>
> *Cc:* Lawrence, Peter <c_plawre at qca.qualcomm.com>; llvm-dev at lists.llvm.org
>
> *Subject:* Re: [llvm-dev] dumb question about tblgen
>
>
>
> The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with
> a class for every type in MachineValueTypes.h
>
>
>
> On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I don’t quite follow why you are doing something like this.
>
>
>
> What is the advantage of this instead of just attaching the AddrRegs
> regsister class as the register class for your instruction?
>
> So that you would have an ADD instruction like
>
> %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2
>
>
>
> What kind of problematic regalloc are you trying to avoid with introducing
> a new backend data type?
>
>
>
> Marcello
>
> On 25 May 2016, at 19:07, Lawrence, Peter via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> Quentin,
>
>               My real problem is that my target has separate address and
> data registers.
>
> The way I’d like to try getting better reg-alloc than I am now is to bring
> out the difference as
>
> Early as possible, so I have added p16, p32, p64 to the enum in
> “MachineValueType.h”
>
>
>
> And I have called  addRegisterClass(MVT::p32,  &XyzAddrRegsRegClass);
>
>
>
> And I have an override for  virtual TargetLowering::getPointerTy()  that
> returns  MVT::p32,
>
>
>
> And some other minor changes that altogether cause virt-regs that contain
> pointers
>
> To get my  AddrRegs  reg-class rather than the “GPR” reg-class that i32
> types get.
>
>
>
>
>
> So far so good, except that llvm-tblgen barfs on “p32”,  so the question
> remains,
>
> How does tblgen know the symbol names “i16”, “i32”, “i64”, etc...
>
>
>
> They don’t seem to come from explicit “def” statements like the symbols
> “add”, “sub”, etc... do
>
> Unless I’m missing something obvious (wouldn’t be the first time!)
>
>
>
> And I’m mystified because my interpretation of reading
> “utils/TableGen/TableGen.cpp”
>
> And “lib/TableGen/Main.cpp”,  Is that the input is fully read and parsed
> before the backend is invoked,
>
> So the back-end can’t be providing symbol-table init for the front-end,
>
> So the definitions have  to be in the input source, but I can’t find them…
>
>
>
>
>
> Thanks,  Peter Lawrence.
>
>
>
>
>
>
>
> *From:* Quentin Colombet [mailto:qcolombet at apple.com <qcolombet at apple.com>
> ]
> *Sent:* Wednesday, May 25, 2016 5:25 PM
> *To:* Lawrence, Peter <c_plawre at qca.qualcomm.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] dumb question about tblgen
>
>
>
> Hi Peter,
>
>
>
> I would recommend looking into the implementation of the matcher if you
> want to add more builtin types:
>
> utils/TableGen//DAGISelMatcherGen.cpp
>
>
>
> That being said, you can define your own types without having to go
> through that hassle.
>
> E.g., from AArch64
>
> def simm9 : Operand<i64>, ImmLeaf<i64, [{ return Imm >= -256 && Imm < 256;
> }]> {
>
>   let ParserMatchClass = SImm9Operand;
>
> }
>
>
>
> Wouldn’t that work for you?
>
>
>
> Cheers,
>
> -Quentin
>
>
>
> On May 25, 2016, at 5:06 PM, Lawrence, Peter via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> Dumb question about llvm-tblgen for “XyzGenInstrInfo.inc”
>
>
>
> If I have a pattern in my dot-td-file like this
>
>
>
>                 [(set i32:$dst   (add i32:$rs1,  i32:$rs2))]
>
>
>
> The question is where does the token “i32” come from,
>
> I don’t see any definitions for i1, i8, i16, i32, …  in
>
>                 include/llvm/Target/*.td
>
>
>
> while I do see definitions for tokens like “set”, “add”, …
>
> coming from
>
>                 include/llvm/Target/TargetSelectionDAG.td
>
>
>
> presumably these tokens are related to the enum in
>
>                 include/llvm/CodeGen/MachineValueType.h
>
> but how does  tblgen know about them,
>
>
>
>
>
> To put the question into context, if I add an item to the enum in
> “MachineValueType.h”
>
> What do I do about
>
>                 “error: Variable not defined:”
>
> Coming from tblgen when I try to use it in my dot-td-file,
>
> I’ve already tried re-building tblgen, but that didn’t help.
>
>
>
>
>
>
>
> thanks,
>
> --Peter Lawrence.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
>
> --
>
> ~Craig
>

-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160525/4af61ec1/attachment-0001.html>