PATCH: SelectionDAG: Use MVT::i32 for vector indices
Tom Stellard
tom at stellard.net
Mon Jul 29 08:22:24 PDT 2013
On Mon, Jul 29, 2013 at 02:41:11PM +0200, Duncan Sands wrote:
> Hi Tom,
>
> >The attached patch ensures that the SelectionDAG always uses MVT::i32
> >for the index operands of EXTRACT_VECTOR_ELT, INSERT_VECTOR_ELT,
> >INSERT_SUBVECTOR, and EXTRACT_SUBVECTOR. MVT::i32 was chosen because
> >the LLVM IR specification uses i32 for all its vector instructions that
> >take an index arguement.
>
> I think this is a bad idea since it assumes that the i32 type is legal for
> all platforms.
>
The first version of this patch that I wrote:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130715/181799.html
added TargetLowering::getVectorIdxTy() which targets could use to specify
whatever type the wanted. What do you think of using the version one patch
instead?
-Tom
> >The previous code was using TargetLowering::getPointerTy() for vector
> >indices. I think the reason for this was to make it easier to handle
> >non-constant vector indices, which required that the vector be
> >stored in memory.
>
> I think the real reason is that an integer type with the same size as a pointer
> is required to be a legal type on all platforms.
>
> >
> >Using TargetLowering::getPointerTy() can be a problem for targets with
> >pointer sizes that differ across address spaces, since the address space
> >used to store the vector may have a different pointer size than the
> >'zero' address space which is what TargetLowering::getPointerTy() uses.
>
> I think this is a different issue to the one of always using an integer type
> that is guaranteed to be legal.
>
> Ciao, Duncan.
>
> >
> >There are two motivations for this patch, the first is to clean
> >up some bad code that is generated when using dynamic indexing
> >of vectors in the R600 target. The second is to reduce the use of
> >TargetLowering::getPointerTy() in the SelectionDAG code which will help
> >anyone who is trying to improve support for targets with pointer sizes
> >that differ across address spaces.
> >
> >Please Review.
> >
> >Thanks,
> >Tom
> >
> >
> >
> >
> >_______________________________________________
> >llvm-commits mailing list
> >llvm-commits at cs.uiuc.edu
> >http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list