llvm dev - Jun 2013 - [LLVMdev] 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130621/d4a822f4/attachment.html>

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

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

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130623/87bf7dd0/attachment.html>