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

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?

Thanks
Alireza Moshtaghi
Senior Software Engineer
Development Systems, Microchip Technology

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

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