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

[John McCall via cfe-commits]

rjmccall added inline comments.

================
Comment at: lib/CodeGen/CGClass.cpp:1279
@@ +1278,3 @@
+  if (CGM.getCodeGenOpts().StrictVPtrs && BaseVPtrsInitialized)
+    CXXThisValue = Builder.CreateInvariantGroupBarrier(LoadCXXThis());
+
----------------
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?


http://reviews.llvm.org/D12312