Re: gcc 4.5.1 -fstrict-aliasing and store removal

[Ian Lance Taylor <iant at google dot com>]

Vyacheslav Egorov <vegorov@chromium.org> writes:

> The question is why this conversions between incompatible pointer
> types allows GCC to remove memory stores to some random memory
> location it does not know anything about?
>
> In some article about strict aliasing I've read that compiler can
> remove the following stores:
>
> inline void init (uint64_t* value, uint32_t hi, uint32_t lo) {
>   uint32_t* p = reinterpret_cast<uint32_t>(value);
>   p[0] = lo;  // can be optimized out when inlined to mk
>   p[1] = hi;  // can be optimized out when inlined to mk
> }
>
> uint64_t mk(uint32_t hi, uint32_t lo) {
>   uint64_t result;
>   init(&result, hi, lo);
> }
>
> But I cannot clearly see why compiler can do that nor I can understand
> why it would be beneficial to do so. And the main mystery for me here
> is how to prevent compiler from doing such optimizations.

This example is also incomplete since result is not used.  I'll assume
that it is returned from mk().

The C/C++ language standards say that a store via a pointer whose type
is uint32_t* can not modify a value whose type is uint64_t.  Therefore,
the compiler knows that the assignments to p[0] and p[1] can not modify
result.  So it can just leave result unchanged.  Then it can see that
the assignments to p[0] and p[1] are not used, and so they can be
discarded.  Finally, result is uninitialized, so the compiler does not
need to return any particular value.  The effect is that compiler can
reduce mk() to a function which does absolutely nothing, and any caller
will simply get whatever value happens to be stored in the return
register when mk() is called.


>> (When your program has an aliasing violation, gcc does unpredictable
>> things. ÂThere is little benefit to speculating about precisely why it
>> did what it did.)
>
> Any optimization done by a compiler is always predictable [unless it
> is bug in optimizer], because compiler has to prove that his
> transformation is correct.

You are right, of course.  When I say unpredictable I mean that the
generated code will not follow any simple rules with respect to the
invalid source code.

> I would like to understand what exactly compiler proved in this case.

Hope this helps.

Ian