[LLVMdev] Making GEP into vector illegal?

Eli Friedman eli.friedman at gmail.com
Wed Oct 15 01:14:32 PDT 2008


On Tue, Oct 14, 2008 at 11:43 PM, Mike Stump <mrs at apple.com> wrote:
> On Oct 14, 2008, at 5:41 PM, Chris Lattner wrote:
>> On Oct 14, 2008, at 4:30 PM, Mike Stump wrote:
>>> On Oct 14, 2008, at 1:54 PM, Eli Friedman wrote:
>>>> Maybe... although note that with gcc vector intrinsics, this
>>>> violates
>>>> strict aliasing.  gcc does allow you to use a slightly more
>>>> elaborate
>>>> workaround with a union, though.
>>>
>>> Hum what's your take on this then:
>>>
>>> /* The Intel API is flexible enough that we must allow aliasing with
>>> other
>>>   vector types, and their scalar components.  */
>>> /* APPLE LOCAL 4505813 */
>>> typedef long long __m64 __attribute__ ((__vector_size__ (8),
>>> __may_alias__));
>>
>> This is actually completely different AFAIK,
>
> 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?

The may_alias you're pointing to was added relatively recently, a bit
before gcc 4.2 was released; note that it only affects stuff using the
_m64 type as opposed to defining a similar vector type.

-Eli



More information about the llvm-dev mailing list