================
@@ -1662,12 +1662,13 @@ def : Flag<["-"], "shared-libasan">, 
Alias<shared_libsan>;
 def : Flag<["-"], "static-libasan">, Alias<static_libsan>;
 def fasm : Flag<["-"], "fasm">, Group<f_Group>;
 
-defm assume_unique_vtables : BoolFOption<"assume-unique-vtables",
-  CodeGenOpts<"AssumeUniqueVTables">, DefaultTrue,
-  PosFlag<SetTrue>,
-  NegFlag<SetFalse, [], [ClangOption, CC1Option],
-          "Disable optimizations based on vtable pointer identity">,
-  BothFlags<[], [ClangOption, CLOption]>>;
+def fassume_unique_vtables : Flag<["-"], "fassume-unique-vtables">,
+  Group<f_Group>, Visibility<[ClangOption, CC1Option, CLOption]>,
+  HelpText<"Assume each polymorphic class has a single vtable with a unique "
+           "address, enabling optimizations based on vtable pointer identity">;
+def fno_assume_unique_vtables : Flag<["-"], "fno-assume-unique-vtables">,
+  Group<f_Group>, Visibility<[ClangOption, CC1Option, CLOption]>,
+  HelpText<"Disable optimizations based on vtable pointer identity">;
----------------
ahatanak wrote:

I went back and forth on this, but I think I'd keep the current spelling.

The internal policy is three-state, but those don't map one-to-one onto things 
a user should request. The middle value (`UniqueIfStrongLinkage`) is an ABI 
property (which vtables the target may duplicate), not a preference, and the 
only target that wants it (Apple Mach-O) already gets it as the default. There 
may be cases where requesting it elsewhere is useful (e.g., to let a target 
that has unique weak vtables still annotate them `unnamed_addr`), but that's 
something to support if someone actually asks for it and design carefully when 
we do. Since driver options are easy to add and hard to remove, I'd rather not 
expose that to the user now.

I also want to walk back what my patch does to `-fassume-unique-vtables`. It 
currently maps to `AlwaysUnique` and forces the optimization on, but originally 
it had no effect of its own. It existed only to cancel prior 
`-fno-assume-unique-vtables`. I'll restore that.

https://github.com/llvm/llvm-project/pull/205929
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to