[llvm-dev] dumb question about tblgen

[Craig Topper via llvm-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160525/29178ea4/attachment.html>