[LLVMdev] Making GEP into vector illegal?

[Daniel M Gessel]

Just for reference, my C example was for my own clarification.

I dived into LLVM having to write a TargetMachine and I've been  
keeping busy without having to learn much IR (yet). I was really  
trying to use C as a pseudo-IR.

I get that the idea is allowing IR to directly express the address of  
part of a vector complicates (prevents?) certain optimizations.

However, due to my own ignorance, I don't understand why.

My first thought was that a GEP to part of a vector shouldn't really  
pose any more complications (restrictions?) than a GEP of the vector  
as a whole. That's what I was trying to get at with my example.

Although I could see how this might complicate, say, mem2reg. I would  
think that if you don't index with the result of a GEP of the whole  
vector (or pass it to a function, or...), then moving it into a  
register is a "clean" operation. However, a GEP of part of the vector  
would immediately put you into a more complicated situation.

Or something like that...

Dan


On Oct 15, 2008, at 11:22 AM, Chris Lattner wrote:

> On Oct 14, 2008, at 11:43 PM, Mike Stump wrote:
>> That statement was that:
>>
>>> float4 a;
>>> float* ptr_z = (float*)(&a) + 3;
>>
>> ``violates strict aliasing``
>>
>> That assertion is wrong.  The docs says:
>>
>> @item may_alias
>> Accesses to objects with types with this attribute are not subjected
>> to
>> type-based alias analysis, but are instead assumed to be able to  
>> alias
>> any other type of objects, just like the @code{char} type.
>>
>> clearly, is _m64 is to be treated as char, then, all stores before it
>> are complete and no loads can be moved before it, unless you can't
>> tell that this happened.  As for what it allows, it allows many
>> things, including the original snippet that was said to violate  
>> strict
>> aliasing.  I can't fathom any other reading, what am I missing?
>
> Aha, gotcha.  I misunderstood the connection.
>
> In any case, the important distinction I wanted to raise was that
> we're talking about how the IR *models a very specific case*, not
> *eliminating a capability* of the IR.
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev