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

[Piotr Padlewski via cfe-commits]

Prazek added inline comments.

================
Comment at: include/clang/Driver/Options.td:990
@@ -988,2 +989,3 @@
            "value range">;
+def fstrict_vptrs: Flag<["-"], "fstrict-vptrs">, Group<f_Group>, Flags<[CC1Option]>;
 def fstrict_overflow : Flag<["-"], "fstrict-overflow">, Group<f_Group>;
----------------
rjmccall wrote:
> This needs documentation for the --help output, something like "Enable optimizations based on the strict rules for overwriting polymorphic C++ objects".
> 
> This option should eventually be promoted to be a driver option, so we might as well figure out the name now.  I'd rather not introduce "vptr" to the user lexicon.  I suggest -fstrict-vtable-pointers.
works for me, if anyone will not come up with better name (or say that the previous name was better) I will change it to fstrict-vtable-pointers

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


http://reviews.llvm.org/D12312