[LLVMdev] Register Class assignment for integer and pointer types

[杨勇勇]

2013/6/25 Tom Stellard <tom at stellard.net>

> 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, 杨勇勇 <triple.yang at gmail.com> 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 <David.Chisnall at cl.cam.ac.uk>
> > > 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, 杨勇勇 <triple.yang at gmail.com> 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
> > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> > >
> > >
> > >
> > > --
> > > 杨勇勇 (Yang Yong-Yong)
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
杨勇勇 (Yang Yong-Yong)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130625/383b8789/attachment.html>