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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
