[LLVMdev] [cfe-dev] GEP index type

Rotem, Nadav nadav.rotem at intel.com
Sat Dec 10 14:06:52 PST 2011


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 ?


-----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

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.

More information about the llvm-dev mailing list