thr3ads.net - llvm dev - [llvm-dev] dumb question about tblgen [May 2016]

If this information is useful, please help other people find it:
Share via:

Lawrence, Peter via llvm-dev

2016-May-26 02:07 UTC

[llvm-dev] dumb question about tblgen

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]
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<mailto: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<mailto:llvm-dev at lists.llvm.org>
http://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/20160526/1f338c61/attachment.html>

Marcello Maggioni via llvm-dev

2016-May-26 03:12 UTC

head link

[llvm-dev] dumb question about tblgen

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] 
> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160525/906d71b1/attachment-0001.html>

Craig Topper via llvm-dev

2016-May-26 04:30 UTC

head link

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

Lawrence, Peter via llvm-dev

2016-May-26 17:06 UTC

head link

[llvm-dev] dumb question about tblgen

Marcello,
                The short answer is this, like you say the register-class for
target machine instructions comes from that instructions’ pattern, but this is
not the case for CopyFromReg and CopyToReg machine instructions, those are
“machine-independent” machine instructions, you currently have little control
over what register-class gets associated with them, in fact the register-class
they get is derived from the MVT, and there is currently no MVT that means
“pointer” (yes, there is MVT::iPTR, but that is not a pointer, it is an integer
with the same size as a pointer, and IIUC it always gets replaced with an
explicitly sized integer type).

The long answer would have a description of how other compilers are typically
more explicit in distinguishing between “local” virtual registers (only live in
a single BB) and “global” virtual registers (live across more than a single BB).
In LLVM “local” virtual registers don’t exist in the SelectionDAG, but “global”
virtual registers are what appear in CopyToReg and CopyFromReg instructions. It
is the register-class of these “global” virtual registers that I need to control
to get “better register allocation” than I am already getting by having
address-register-class specifications on my pointer-arithmetic instructions.

If you have any better ideas I’m all ears.  It is conceivable that re-designing
the logic around “MVT::iPTR” could be made to work, but I don’t know enough yet
about TableGen and CodeGen to say whether that is possible, or even plausible,
and then the notion of “an integer the same size as a pointer” is a fairly
firmly established concept, it might not be prudent to mess with it.

Thanks,
--Peter Lawrence.

From: mmaggioni at apple.com [mailto:mmaggioni at apple.com]
Sent: Wednesday, May 25, 2016 8:12 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
Cc: Quentin Colombet <qcolombet at apple.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] dumb question about tblgen

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<mailto: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]
Sent: Wednesday, May 25, 2016 5:25 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at
qca.qualcomm.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto:llvm-dev at lists.llvm.org>
http://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/20160526/49aacfa6/attachment.html>

Apparently Analagous Threads

Search for more apparently analagous threads

llvm dev - May 2016 - dumb question about tblgen

[llvm-dev] dumb question about tblgen

[llvm-dev] dumb question about tblgen

[llvm-dev] dumb question about tblgen

[llvm-dev] dumb question about tblgen

Apparently Analagous Threads