[PATCH] D12312: Emiting invariant.group.barrier and adding -fstrict-vptrs

[Piotr Padlewski via cfe-commits]

Prazek marked 3 inline comments as done.

================
Comment at: lib/CodeGen/CGClass.cpp:1279
@@ +1278,3 @@
+  if (CGM.getCodeGenOpts().StrictVPtrs && BaseVPtrsInitialized)
+    CXXThisValue = Builder.CreateInvariantGroupBarrier(LoadCXXThis());
+
----------------
rjmccall wrote:
> Prazek wrote:
> > rjmccall wrote:
> > > Prazek wrote:
> > > > rjmccall wrote:
> > > > > Should this just be in InitializeVTablePointers?
> > > > I want to add invariant.group.barrier only if it's needed. F.e. I don't want to put before I initialize vptrs for base, or when my class doesn't inherit frome anything. I want emit barrier after I will initialize some other vptrs.
> > > > 
> > > > InitializeVptrs is called in EmitBaseInitializer, and also I woudnt want to put some extra flag if it must produce barrier or not (because it is hard to distinguish it from inside)
> > > Fair enough.
> > > 
> > > Do we need to emit these barriers in unoptimized builds?
> > It depends - if we will not add invariant.group metadata to loads/stores without optimizations, then we can not add theis invariant barrier stuff. 
> > My question is, if I will run clang
> > 
> > clang++ stuff.cpp -O0 -fstrict-vptrs 
> > 
> > does it mean, that I don't want any optimizations, or it means that I don't want any optimizations except strict-vptrs?
> > If answer is second one, then I think not checking for optimizations is fine (If we will change it to be default, then we will have to add Optmizations turned check)
> Well, we're not actually going to do the optimizations at -O0 in any case, and "please emit the information necessary to do the optimizations without actually doing them" is not an intermediate state that users actually want.
> 
> The basic problem here continues to be that, as designed, this optimization is unsound without cooperation from every module that emitted any IR.  In order for this optimization to qualify as a non-experimental feature, you will need to actually fix that so that it decays gracefully in the presence of a non-cooperating module.  Once you do that, it will also be reasonable to omit these barriers at -O0.
> 
> When we talked about this before, we had a workable, if conservative, plan for how to implement that graceful decay: you need to tag cooperating functions and then untag them when information is merged (e.g. by the inliner) from non-cooperating functions.  Do you still see that as practical?
Ok, I think I won't add invariant.barrier with O0.

I want to concentrate on !invariant.group optimization more now, so for now the plan is this:

 if we are in O0, then we don't care at all about invariant.group.barrier, we just skip emiting it.
If we are in opt, and fstrict-vtable-pointers is true, then we will add module metadata about it
and when LTO will try to link 2 modules
one with strict-vptrs and one without
then for now, we can just raise an error.
In the future we can strip invariant stuff from module without flag.

Because optimizer doesn't care about invariant.group.barrier now, I will add module metadata in next patch.


http://reviews.llvm.org/D12312