[PATCH] D152741: [WPD] implement -funknown-vtable-visibility-filepaths

[Wenlei He via Phabricator via cfe-commits]

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