Diff Detail
Event Timeline
@rsmith I wonder If we have to put invariant.group.barrier when we call regular new expression
You should add a test that actually checks that your feature works.
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1289 | Should this just be in InitializeVTablePointers? |
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1289 | 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) |
include/clang/Driver/Options.td | ||
---|---|---|
991 | 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. | |
lib/CodeGen/CGClass.cpp | ||
1289 | Fair enough. Do we need to emit these barriers in unoptimized builds? | |
1501 | Grammar: "Insert the llvm.invariant.group.barrier intrinsic before initializing the vptrs to cancel any previous assumptions we might have made." |
include/clang/Driver/Options.td | ||
---|---|---|
991 | 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 | |
lib/CodeGen/CGClass.cpp | ||
1289 | It depends - if we will not add invariant.group metadata to loads/stores without optimizations, then we can not add theis invariant barrier stuff. 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? |
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1289 | 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? |
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1289 | 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. Because optimizer doesn't care about invariant.group.barrier now, I will add module metadata in next patch. |
LGTM.
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1234 | "Initializer" But I think you can just inline this into the one call site as BaseInit->getType()->getAsCXXRecordDecl()->isDynamicClass(). |
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.