Ensure that the vptr store in the most-derived constructor is not behind
an invariant group barrier. Previously, the base-most vptr store would
be the one behind no barrier, and that could result in the creator of
the object thinking it had the base-most vtable.
This bug caused clang call pure virtual functions when called from
constructor body.
http://reviews.llvm.org/D13373
llvm-svn: 249197
It is dangerous to do LTO on code with strict-vtable-pointers, because
one module has invariant.group.barriers, and the other one not.
In the future I want to just strip all invariant.group metadata from
vptrs loads/stores and get rid of invariant.group.barrier calls.
http://reviews.llvm.org/D12580
llvm-svn: 247724