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

> 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

On Aug 19, 2008, at 4:14 PM, Alireza.Moshtaghi at microchip.com wrote:
>> 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)
I realize that sign extensions have non-zero impact when they exist in  
the .s file.  My assertion is that these will be zapped by the dag  
combiner.  Have you actually tried this?
> On x86; but the sign extension does not get eliminated while lowering
> the GEP.
That is because X86 has a 32-bit pointer.  If you have a 16-bit  
pointer, a sign extend from 16 bits to 16 bits will get deleted.

-Chris

> I realize that sign extensions have non-zero impact when they exist in
> the .s file.  My assertion is that these will be zapped by the dag
> combiner.  Have you actually tried this?
Yes, I have and they work just fine for us. I misunderstood your first
email, I thought you are pointing at a problem, while you are actually
saying that there is no problem.

So back to my original question...
Would adding i16 to indexValid() do the trick? Or we need to do more?

Thanks
A.