[LLVMdev] [cfe-dev] GEP index type

Duncan Sands baldrick at free.fr
Sun Dec 11 00:38:33 PST 2011

Hi Nadav,

> I understand the need to widen unsigned types. However, I ran into a problem with the current GEP/subscript that clang has.
> AVX2 gather instructions rely on a 64-bit base pointer and a vector of 32-bit indices. Usually, when vectorizing programs, it is possible to detect that the GEP base pointer is uniform and that the index is variant (and needs to be vectorized). This works really nice for 32-bit programs, except that on 64-bit systems clang drops the information that the index is a 32-bit value. If I had this information then I would have been able to use the AVX2 instruction in many cases.
> Do you see a way to overcome this problem ?  Since InstCombiner has this optimization, can we talk about dropping this optimization in clang ?

I think this is an LLVM optimization: GEP indices are extended to an index type
with the same size as a pointer.

Ciao, Duncan.

> Nadav
> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> Sent: Saturday, December 10, 2011 23:48
> To: Rotem, Nadav
> Cc: cfe-dev at cs.uiuc.edu Developers
> Subject: Re: [cfe-dev] GEP index type
> On Sat, Dec 10, 2011 at 9:20 AM, Rotem, Nadav<nadav.rotem at intel.com>  wrote:
>> Hi,
>> I have a question regarding the LLVM-IR which is generated by clang. When I compile the code below on a 64-bit system, clang generates a GEP instruction with a 64 bit index.
>> int demo(int *A, short i) { return A[i]; }
>> becomes:
>> %4 = sext i16 %3 to i64
>> %6 = getelementptr inbounds i32* %5, i64 %4
>> I would expect to see an i16 index, since the index is known to be within the 0..16 bit range. Why does clang widen the index to a 64bit value ?
> Primarily because this exposes the sign extension to the optimizer,
> which is generally good; iIRC, instcombine does the same thing.
> Also, in some cases we have to do the extension explicitly to preserve
> the IR semantics: for example, suppose "i" was declared as an unsigned
> short.
> -Eli
> ---------------------------------------------------------------------
> 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

More information about the llvm-dev mailing list