Register Class assignment for integer and pointer types

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Register Class assignment for integer and pointer types

杨勇勇
llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.

However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.

I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.

Thanks.

--
杨勇勇 (Yang Yong-Yong)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

David Chisnall-5
We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.

David

On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:

> llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
>
> However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
>
> I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
>
> Thanks.
>
> --
> 杨勇勇 (Yang Yong-Yong)
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

杨勇勇
David, thanks for your immediate response.

Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?

On the other hand, it can be simply treated as a register class assignment problem during register allocation.
Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.

So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?

Regards.

2013/6/21 David Chisnall <[hidden email]>
We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.

David

On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:

> llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
>
> However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
>
> I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
>
> Thanks.
>
> --
> 杨勇勇 (Yang Yong-Yong)
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




--
杨勇勇 (Yang Yong-Yong)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

杨勇勇
In reply to this post by David Chisnall-5
David, thanks for your immediate response.

Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?

On the other hand, it can be simply treated as a register class assignment problem during register allocation.
Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.

So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?

Regards.

2013/6/21 David Chisnall <[hidden email]>
We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.

David

On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:

> llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
>
> However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
>
> I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
>
> Thanks.
>
> --
> 杨勇勇 (Yang Yong-Yong)
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




--
杨勇勇 (Yang Yong-Yong)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

David Chisnall-5
Hi,

In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off.  

Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.

David

On 23 Jun 2013, at 15:49, 杨勇勇 <[hidden email]> wrote:

> David, thanks for your immediate response.
>
> Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?
>
> On the other hand, it can be simply treated as a register class assignment problem during register allocation.
> Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.
>
> So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?
>
> Regards.
>
> 2013/6/21 David Chisnall <[hidden email]>
> We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.
>
> David
>
> On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:
>
> > llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
> >
> > However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
> >
> > I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
> >
> > Thanks.
> >
> > --
> > 杨勇勇 (Yang Yong-Yong)
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> --
> 杨勇勇 (Yang Yong-Yong)


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

杨勇勇



2013/6/23 David Chisnall <[hidden email]>
Hi,

In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off. 

Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.

In our processor, addresses (i.e. pointers) must be assigned to a specific kind of registers before it can be used for memory access, which is the common part between yours and ours.

Here are 2 possible solutions for our problem:
1. constrain instruction selection.
1.1  use    "addRegisterClass(MVT::iPTR,  XXX::PTRRegClass);" to bind pointers and their register class.
1.2  add a pass to transform ISelDAG before instruction selection. Since we can determine from opcodes whether an operation can only take address registers as its input operands, we replace i32 with iPTR if so, and insert reg-reg move operations if necessary. For example, (load reg,  addr:i32) means we read at 'addr' to fill 'reg'. Here, we modify it to (load reg,  addr:iPTR).
1.3  in XXXInstrInfo.td, we give (load  reg,   iPTR:$addr) to match pattern.
1.4  and finally we "hope" default register allocator do the proper thing.

2. add an annotation pass before register allocation.
2.1  we treat both integer and pointer as i32, and hence there is just "addRegisterClass(MVT::i32,  XXX::I32RegClass);"
2.2  before register allocation we annote operands if they must reside in address register.
2.3  register allocation assigns register class according to annotations mentioned in 2.2, and perhaps a custom register allocator has to be implemented.

Which way do you think is more feasible?

Regards.



David

On 23 Jun 2013, at 15:49, 杨勇勇 <[hidden email]> wrote:

> David, thanks for your immediate response.
>
> Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?
>
> On the other hand, it can be simply treated as a register class assignment problem during register allocation.
> Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.
>
> So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?
>
> Regards.
>
> 2013/6/21 David Chisnall <[hidden email]>
> We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.
>
> David
>
> On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:
>
> > llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
> >
> > However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
> >
> > I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
> >
> > Thanks.
> >
> > --
> > 杨勇勇 (Yang Yong-Yong)
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> --
> 杨勇勇 (Yang Yong-Yong)




--
杨勇勇 (Yang Yong-Yong)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

David Chisnall-5
On 24 Jun 2013, at 04:50, 杨勇勇 <[hidden email]> wrote:

> 2013/6/23 David Chisnall <[hidden email]>
> Hi,
>
> In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off.
>
> Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.
>
> In our processor, addresses (i.e. pointers) must be assigned to a specific kind of registers before it can be used for memory access, which is the common part between yours and ours.

Ah, you only have one kind of pointer?  This is a difference with our architecture.  We have a set of addressing modes that are implicitly indirected through one of the address registers and so we have two different sizes of pointer with different instructions operating on them.

> Here are 2 possible solutions for our problem:
> 1. constrain instruction selection.
> 1.1  use    "addRegisterClass(MVT::iPTR,  XXX::PTRRegClass);" to bind pointers and their register class.
> 1.2  add a pass to transform ISelDAG before instruction selection. Since we can determine from opcodes whether an operation can only take address registers as its input operands, we replace i32 with iPTR if so, and insert reg-reg move operations if necessary. For example, (load reg,  addr:i32) means we read at 'addr' to fill 'reg'. Here, we modify it to (load reg,  addr:iPTR).
> 1.3  in XXXInstrInfo.td, we give (load  reg,   iPTR:$addr) to match pattern.
> 1.4  and finally we "hope" default register allocator do the proper thing.
>
> 2. add an annotation pass before register allocation.
> 2.1  we treat both integer and pointer as i32, and hence there is just "addRegisterClass(MVT::i32,  XXX::I32RegClass);"
> 2.2  before register allocation we annote operands if they must reside in address register.
> 2.3  register allocation assigns register class according to annotations mentioned in 2.2, and perhaps a custom register allocator has to be implemented.
>
> Which way do you think is more feasible?

I think either should work as a short-term hack.  Longer term, I'd like to see TableGen lose two assumptions:

1) Pointers are integers
2) All pointers are the same size

This would make it much easier to support architectures with segmented memory model and various GPUs.

David


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

Tom Stellard-3
In reply to this post by David Chisnall-5
On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote:
> Hi,
>
> In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off.  
>

I've been following this thread, and I just wanted to mention that we
have a similar problem for newer GPU targets in the R600 backend where
pointers for image reads and writes can be 128 or 256 bits and the
largest integer type we support is i64.  Luckily, since image reads and
writes aren't something you can do in a 'normal' C or C++ program we can
get away with using special intrinsics that return the fat pointers,
which we model using v16i8 and v32i8 types.  However, as we improve
support for OpenCL and other compute oriented programming languages,
we may need to starting using 'real' pointers.

> Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.
>

We also have a somewhat related issue with newer GPUs, that have
essentially two different instruction sets.  However, instead of having
one for pointers and one for integers like your target, we have a Vector
ALU (VALU) for manipulating integers and floats and a Scalar ALU (SALU)
for handling control flow and loading for constant memory.  There is a
lot overlap between these two instruction sets (i.e both support almost
all standard integer operations).  Since tablegen matches patterns based
on types, it is impossible for us to select from both instruction sets,
and it sounds like you will have the same problem if you treat pointers as
integer types.

To make matters worse, you can only copy registers between
the ALUs in one direction.  SALU to VALU is legal, but VALU to SALU isn't.
Currently we do post processing on the DAG after instruction selection
to help avoid these illegal copies.  I've considered also adding post
processing to help select the optimal instruction type (VALU or SALU),
but I think something like this may be easier to handle in a
pre-regalloc scheduler pass.

Not sure if any of this information will help you, but sometimes it's
just nice to know that you're not the only one with a strange target ;)

-Tom


> David
>
> On 23 Jun 2013, at 15:49, 杨勇勇 <[hidden email]> wrote:
>
> > David, thanks for your immediate response.
> >
> > Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?
> >
> > On the other hand, it can be simply treated as a register class assignment problem during register allocation.
> > Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.
> >
> > So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?
> >
> > Regards.
> >
> > 2013/6/21 David Chisnall <[hidden email]>
> > We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.
> >
> > David
> >
> > On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:
> >
> > > llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
> > >
> > > However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
> > >
> > > I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
> > >
> > > Thanks.
> > >
> > > --
> > > 杨勇勇 (Yang Yong-Yong)
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
> >
> > --
> > 杨勇勇 (Yang Yong-Yong)
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

杨勇勇



2013/6/25 Tom Stellard <[hidden email]>
On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote:
> Hi,
>
> In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off.
>

I've been following this thread, and I just wanted to mention that we
have a similar problem for newer GPU targets in the R600 backend where
pointers for image reads and writes can be 128 or 256 bits and the
largest integer type we support is i64.  Luckily, since image reads and
writes aren't something you can do in a 'normal' C or C++ program we can
get away with using special intrinsics that return the fat pointers,
which we model using v16i8 and v32i8 types.  However, as we improve
support for OpenCL and other compute oriented programming languages,
we may need to starting using 'real' pointers.

> Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.
>

We also have a somewhat related issue with newer GPUs, that have
essentially two different instruction sets.  However, instead of having
one for pointers and one for integers like your target, we have a Vector
ALU (VALU) for manipulating integers and floats and a Scalar ALU (SALU)
for handling control flow and loading for constant memory.  There is a
lot overlap between these two instruction sets (i.e both support almost
all standard integer operations).  Since tablegen matches patterns based
on types, it is impossible for us to select from both instruction sets,
and it sounds like you will have the same problem if you treat pointers as
integer types. 

To make matters worse, you can only copy registers between
the ALUs in one direction.  SALU to VALU is legal, but VALU to SALU isn't.
Currently we do post processing on the DAG after instruction selection
to help avoid these illegal copies.  I've considered also adding post
processing to help select the optimal instruction type (VALU or SALU),
but I think something like this may be easier to handle in a
pre-regalloc scheduler pass.

Not sure if any of this information will help you, but sometimes it's
just nice to know that you're not the only one with a strange target ;)

Aha, that makes two of us. Thank you!

You newer GPU is much more complicated than our prototype DSP.

I am about to add a pre-isel pass to tag DAGNodes and replace operand types with some target-specific ones, then let built-in instruction selector do its job. Hope this work out for me.

Regard!
 

-Tom


> David
>
> On 23 Jun 2013, at 15:49, 杨勇勇 <[hidden email]> wrote:
>
> > David, thanks for your immediate response.
> >
> > Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?
> >
> > On the other hand, it can be simply treated as a register class assignment problem during register allocation.
> > Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.
> >
> > So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?
> >
> > Regards.
> >
> > 2013/6/21 David Chisnall <[hidden email]>
> > We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.
> >
> > David
> >
> > On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:
> >
> > > llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.
> > >
> > > However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.
> > >
> > > I have already read this mail thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html , and I am wondering how is the progress about it.
> > >
> > > Thanks.
> > >
> > > --
> > > 杨勇勇 (Yang Yong-Yong)
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > [hidden email]         http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
> >
> > --
> > 杨勇勇 (Yang Yong-Yong)
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
杨勇勇 (Yang Yong-Yong)

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Register Class assignment for integer and pointer types

Hal Finkel
In reply to this post by Tom Stellard-3
----- Original Message -----

> On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote:
> > Hi,
> >
> > In our version of LLVM, we've added different-sized iPTR* types, so
> > we have an iPTR256 for our fat pointers.  This causes some
> > problems with constraints, because the way that TableGen resolves
> > constraints is not expected to handle multiple pointer types.
> >  We've added a flag that can be set on a per-backend basis to turn
> > this off.
> >
>
> I've been following this thread, and I just wanted to mention that we
> have a similar problem for newer GPU targets in the R600 backend
> where
> pointers for image reads and writes can be 128 or 256 bits and the
> largest integer type we support is i64.  Luckily, since image reads
> and
> writes aren't something you can do in a 'normal' C or C++ program we
> can
> get away with using special intrinsics that return the fat pointers,
> which we model using v16i8 and v32i8 types.  However, as we improve
> support for OpenCL and other compute oriented programming languages,
> we may need to starting using 'real' pointers.
>
> > Our problem is perhaps a bit different form yours, as our pointers
> > must be loaded and manipulated via special instructions, they can
> > not use the integer instructions or registers.
> >
>
> We also have a somewhat related issue with newer GPUs, that have
> essentially two different instruction sets.  However, instead of
> having
> one for pointers and one for integers like your target, we have a
> Vector
> ALU (VALU) for manipulating integers and floats and a Scalar ALU
> (SALU)
> for handling control flow and loading for constant memory.  There is
> a
> lot overlap between these two instruction sets (i.e both support
> almost
> all standard integer operations).  Since tablegen matches patterns
> based
> on types, it is impossible for us to select from both instruction
> sets,
> and it sounds like you will have the same problem if you treat
> pointers as
> integer types.
>
> To make matters worse, you can only copy registers between
> the ALUs in one direction.  SALU to VALU is legal, but VALU to SALU
> isn't.
> Currently we do post processing on the DAG after instruction
> selection
> to help avoid these illegal copies.  I've considered also adding post
> processing to help select the optimal instruction type (VALU or
> SALU),
> but I think something like this may be easier to handle in a
> pre-regalloc scheduler pass.
>
> Not sure if any of this information will help you, but sometimes it's
> just nice to know that you're not the only one with a strange target
> ;)

This discussion reminds me of the issue that PowerPC has, not with pointers, but with condition-code registers. These condition-code registers have a complete set of logical operation instructions (and, or, etc.) that can be applied to them, and we'd probably like to use those instructions on the results of comparisons as appropriate. However, moving data from regular integer registers into condition-code bits is relatively expensive, and so we don't want to select these condition-code logical operation instructions just based on local data-type information.

 -Hal

>
> -Tom
>
>
> > David
> >
> > On 23 Jun 2013, at 15:49, 杨勇勇 <[hidden email]> wrote:
> >
> > > David, thanks for your immediate response.
> > >
> > > Since iPTR is a reserved type for tablegen internal use, can you
> > > make a further explanation?
> > >
> > > On the other hand, it can be simply treated as a register class
> > > assignment problem during register allocation.
> > > Assume both pointer and integet have a 32 bit width. backend
> > > handles it just as to i32. When it performs register allocation,
> > > it can retrieve from target constraint information about which
> > > register class is valid for a operand, and this is determined by
> > > which instruction consumes the operand.
> > >
> > > So is there a convienient way to constrain register class
> > > assignment, like a tablegen interface or something else?
> > >
> > > Regards.
> > >
> > > 2013/6/21 David Chisnall <[hidden email]>
> > > We also have this problem, and have added iPTR types to the back
> > > end.  Our pointers are actually fat pointers, so this also
> > > requires tweaking some optimisations (for example, things like
> > > to turn GEPs with 64-bit offsets into pointer-sized offsets, but
> > > our pointers are larger than any integer type that we
> > > support...).  Most of the changes are a bit ugly, and I'm loath
> > > to upstream them without an in-tree target that has these
> > > requirements, or they will be hard for anyone else to keep
> > > working.
> > >
> > > David
> > >
> > > On 21 Jun 2013, at 06:00, 杨勇勇 <[hidden email]> wrote:
> > >
> > > > llvm code generator lowers both integer and pointer types into
> > > > ixx(say, i16, i32, i64, ...). This make senses for some
> > > > optimizations.
> > > >
> > > > However, integer registers and pointer registers is expilicitly
> > > > distinguished from each other for some architectures, like
> > > > TriCore, Blackfin, and our lab prototype dsp, which
> > > > accelerates address computation and memory access.
> > > >
> > > > I have already read this mail thread:
> > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html
> > > > , and I am wondering how is the progress about it.
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > 杨勇勇 (Yang Yong-Yong)
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > [hidden email]         http://llvm.cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> > >
> > >
> > >
> > > --
> > > 杨勇勇 (Yang Yong-Yong)
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev