r218141 - In the Itanium ABI, move stuff to the comdat of variables with static init.

[Richard Smith]

(Adding back cfe-commits, I removed it accidentally)

On Wed, Dec 17, 2014 at 3:48 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
>
> >> The only option I can think of that would wold work is to use comdas
> >> like now, but to always produce a guard variable. So when the variable
> >> is found to be a constant, we would have
> >>
> >> @_ZGVZ1fvE1y = linkonce_odr constant i64 1, comadat $_Z1fv
> >
> >
> > That's not sufficient: if the function is taken from the TU with constant
> > initialization, the variable won't be initialized. You need to both emit
> a
> > guard variable initialized to 1, *and* emit the initialization code. (But
> > only in the rare and detectable case where we can have dynamic init in
> > another TU.)
>
> I see. That is also broken in gcc. Testcases attached. Run with
>
> CXX -c test2.cpp -fPIC -g
> $CXX -c test.cpp -O2 -fPIC -g
> $CXX test.o test2.o -o t
> ./t
>
> The comparison will fail since we read a 0.
>
> So you suggestion is that in the case of a known constant that might
> not be constant in another TU we emit something like the attached t.ll
> file.
>
> Things to note:
>
> * The variable and the guard are in the same comdat.
> * The function is in its own comdat.
> * The variable is initialized to 42 and the guard to 1
> * Both the variable and the guard are linkonce, not linkonce_odr,
> otherwise llvm could optimize the comparison away.
> * The function has the regular dynamic initialization. Just doing a
> "store i32 42, i32* @_ZZ1fvE1y, align 4" would cause a race condition,
> no?
>

Yes; what I meant was to use the normal guarded initialization, but the
actual initialization step would simply be a copy of the known constant
value to the variable (that is, exactly what your code does).

That IR looks right, except _Z1fv should be 'linkonce_odr' rather than
'define' =)


> I will revert the patch for now.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141217/0584d1fd/attachment.html>