[LLVMdev] Extending Vector GEP - proposal

Nadav Rotem nrotem at apple.com
Mon Mar 2 09:00:49 PST 2015


I don’t have a strong opinion on this. The current GEP syntax is more restrictive and the single base pointer case can be emulated using a broadcast + vector-gep, that can easily be patten matched at codegen time. The problem with the current syntax is that the ‘broadcast’ instruction can be hoisted outside of loops and this can be a problem with our "one block at a time" codegen implementation. This problem can be solved by sinking the broadcast instruction at codegen-prepare time. 

Is there a strong motivation to prefer one representation over the other?


> On Mar 1, 2015, at 2:10 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote:
> 
> Hi,
>  
> According to the current GEP syntax, vector GEP requires that each index must be a vector with the same number of elements.
>  
> %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets
>  
> I propose to lessen this requirement. Let each index be or vector or scalar. All vector indices must have the same number of elements. The scalar value will mean the splat vector value.
>  
> %A = getelementptr i8* %ptr, <4 x i64> %offsets
> or
> %A = getelementptr <4 x i8*> %ptrs, i64 %offset
>  
> In this case we don’t have to add a “broadcast” before GEP. It is actually will be developer’s decision what form to choose.
> I plan to use vector GEP in gather/scatter and the “broadcasting” of the scalar value impedes to narrow this operation to the “common base, multiple indices” form in the future.
>  
> What do you think?
> Thanks.
>  
> Elena
>  
>  
>  
> ---------------------------------------------------------------------
> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150302/121b1a50/attachment.html>


More information about the llvm-dev mailing list