llvm dev - Aug 2008 - [LLVMdev] hard values in SequentialType::indexValid () method

What is the reason for getelementptr being tied to only 32 or 64 bit
indexes? It seems to me that integer size would be better choice...
 
Anyways, this is getting in our way. What is your suggestion?

Thanks
Ali
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
On
> Behalf Of Chris Lattner
> Sent: Monday, August 18, 2008 4:33 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] hard values in SequentialType::indexValid ()
method
> 
> 
> On Aug 18, 2008, at 4:20 PM, Alireza.Moshtaghi at microchip.com wrote:
> 
> > This method is defined in:
> > Lib/VMCore/Type.cpp
> > And it makes hard assumption that size of integer is 32 or 64.
> > This gives us trouble because we have 16 bit integer.
> > Is there a reason for this assumption? Or we can just add the 16-bit
> > integer to it as well?
> 
> Hi Alireza,
> 
> The reason for this is that the getelementptr instruction is spec'd to
> take either an i32 or i64.  We could extend this, but it probably
> won't make a difference in practice.  If the front-end generates code
> like:
> 
> 
> %tmp = sext i16 %idx to i32
> %tmp2 = getelementptr float* %P, i32 %tmp
> 
> Then the llvm code generator will squish the sign extension etc when
> it lowers GEP to pointer arithmetic.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Aug 19, 2008, at 6:54 AM, Alireza.Moshtaghi at microchip.com
wrote:
> What is the reason for getelementptr being tied to only 32 or 64 bit
> indexes?
As usual, the answer is "that is all anyone has needed so far" :)
> Anyways, this is getting in our way. What is your suggestion?
Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ 
zero extension instructions.

Does this actually affect the code being generated in practice?

-Chris

> Two options: 1) change LLVM IR to allow it, or 2) just insert sign/
> zero extension instructions.
> 
> Does this actually affect the code being generated in practice?
Inserting sign/zero extension instructions actually do tend to increase
the generated code pretty dramatically on our target. So I prefer option
(1)

Does this change have dramatic affect on LLVM IR?

PS.
Currently (in our local code repository) we have modified the
indexValid() method to also allow i16 and so far our test cases are
going through. 
I also tried :

float *p1;
float *p3;
short i;
...
p1 = p2 + i;

to generate your example:

%tmp = sext i16 %idx to i32
%tmp2 = getelementptr float* %P, i32 %tmp

On x86; but the sign extension does not get eliminated while lowering
the GEP.
Maybe I understand better if you could give me a C code that shows the
difference.

Thanks
Ali