wenlei added a comment.
> For concrete data are you talking about between the different solutions e.g.
> --lto-whole-program-visibility, -funknown-vtable-visibility-filepaths, RTTI
> based, FatLTO based etc or something else?
Right, between the different solutions. RTTI based solution doesn't exist yet,
so maybe just compare using `-fwhole-program-vtables` on a known safe set of
files vs using `-funknown-vtable-visibility-filepaths` on a known unsafe set of
files first.
> Some data would help quantify the difference, I'll hack up a module
> granularity implementation and compare to the current one.
I wasn't asking about implementing `-funknown-vtable-visibility-filepaths` with
module (instead of header) granularity, but just the comparison mentioned above.
> The ordering for conflicts is embedded in the logic for
> CodeGenModule::GetVCallVisibilityLevel which has priority order of
I was thinking about different source of visibility instead of absolute order
of visibility itself - i.e. what is the rule if
`__attribute__((visibility("...")))` conflicts with
`-funknown-vtable-visibility-filepaths` setting for a specific type? This may
not be an immediately important question, but just as example of the knock on
effect of added complexity, which may or may not be justified depending on the
benefit, which goes back to data from experiments.
We have `-wholeprogramdevirt-skip`; with this patch, we will have
`-funknown-vtable-visibility-filepaths`; later on, we will have another RTTI
based solution, then there's FatObj solution. It feels like a lot of stuff
trying to solve one problem, so wondering if this addition here is going to
provide enough value in the end state.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D152741/new/
https://reviews.llvm.org/D152741
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
