[llvm-commits] Vectors of Pointers and Vector-GEP

[Rotem, Nadav]

Ping.

-----Original Message-----
From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav
Sent: Thursday, November 24, 2011 22:48
To: Chris Lattner; Duncan Sands
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP

Hi Chris, Duncan, 

The attached patch has it all: store, load, alloca, shuffle, insert, extract, bitcast, inttoptr, ptrtoinst, and GEP.

This patch is not too big, and most of it is tests and docs. 

Thanks,
Nadav  




-----Original Message-----
From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner
Sent: Thursday, November 24, 2011 19:36
To: Duncan Sands
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP


On Nov 24, 2011, at 7:21 AM, Duncan Sands wrote:

> Hi Nadav, I think Chris should at least give his blessing before you 
> start changing the IR.

I think that this makes perfect sense.  In terms of implementation roll-out though, I'd suggest generalizing one piece at a time: first allow vector of pointers (resolving the target data issues) with just load/store/insert/extract/shuffle, then add bitcast/inttoptr/ptrtoint, then GEP.  This way we have a working and self consistent compiler all along the way.

-Chris

> 
> Ciao, Duncan.
> 
> On 24/11/11 12:56, Rotem, Nadav wrote:
>> Ping.
>> 
>> 
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu 
>> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav
>> Sent: Wednesday, November 23, 2011 22:10
>> To: Duncan Sands; llvm-commits at cs.uiuc.edu; LLVM Developers Mailing 
>> List
>> Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and 
>> Vector-GEP
>> 
>> Duncan,
>> 
>> Thanks for the quick review! Here is a short description (design) of where I am going with this patch:
>> 
>> 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type.
>> 
>> 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions:
>> 	a. Bitcast to other vector-of-pointers, as long as the element count is the same.
>> 	b. No other bit-cast operations are allowed.
>> 3. The type Vectors-of-pointers can be used by the following instructions:
>> 	a. Insertelement/extractelement/shuffle - just like any other vector
>> 	b. Getelementptr - for address calculations, with the restrictions mentioned below.
>> 	c. Intrinsics - to implement the scatter/gather operations
>> 	d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch].
>> 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point.
>> 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers.
>> 
>> Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this.
>> 
>> Thank you,
>> Nadav
>> 
>> 
>> 	
>> 
>> 
>> -----Original Message-----
>> From: llvm-commits-bounces at cs.uiuc.edu 
>> [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands
>> Sent: Wednesday, November 23, 2011 11:36
>> To: llvm-commits at cs.uiuc.edu
>> Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP
>> 
>> Hi Nadav,
>> 
>>> Following the discussion in last week's LLVM developers conference I 
>>> started working on support for vectors-of-pointers. Vectors of 
>>> pointers are needed for supporting scatter/gather operations and are 
>>> the first step in the direction of supporting predicated 
>>> architectures. In the attached patch, I change the LLVM-IR in order to support vectors-of-pointers and added basic support for vector-gep.
>>> In following patches I plan to extend the vector-gep support to more 
>>> indices and add scatter/gather intrinsics.
>> 
>> one of the issues with vectors-of-pointers is then you can no longer 
>> say what the size of a vector is without target data, since you don't 
>> know what the size of a pointer is without target data.  Methods like 
>> VectorType::getBitWidth will have to be deleted.  Methods like 
>> VectorType::getTruncatedElementVectorType,
>> VectorType::getExtendedElementVectorType and VectorType::getInteger 
>> will need to either be removed, or changed to take a target data 
>> parameter (which is probably a layering violation, so they would need 
>> to be moved elsewhere).  The PtrToInt and IntToPtr operations will 
>> need to be enhanced to work on vectors, and a bunch of places that 
>> bitcast vectors will need to become more careful, in case they are 
>> trying to bitcast between a vector of pointers and a vector of integers.
>> 
>> Ciao, Duncan.
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>> 
>> This e-mail and any attachments may contain confidential material for 
>> the sole use of the intended recipient(s). Any review or distribution 
>> by others is strictly prohibited. If you are not the intended 
>> recipient, please contact the sender and delete all copies.
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>> 
>> This e-mail and any attachments may contain confidential material for 
>> the sole use of the intended recipient(s). Any review or distribution 
>> by others is strictly prohibited. If you are not the intended 
>> recipient, please contact the sender and delete all copies.
>> 
>> 
>> _______________________________________________
>> 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
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.