[WPD] implement -funknown-vtable-visibility-filepaths

[modimo]

Summary

The current WPD system is opt-in on a per-file basis with -fvisibility=hidden or on the entire LTO unit with --lto-whole-program-visibility. For types that are known to be in prebuilt native binaries there's no good way to exclude them outside of selectively removing -fvisibility=hidden or enumerating all their devirt sites with -mllvm -wholeprogramdevirt-skip=.

The idea behind -funknown-vtable-visibility-filepaths is that the interface between our built from source LTO unit files and the native binaries are header files packaged alongside the native binaries that are usually located in specific directories (e.g. third-party). Identifying these types automatically and excluding them from participating in WPD is a lightweight solution to enabling WPD correctly in these scenarios without any additional changes.

Ultimately, we're aiming for a more robust checked solution but this provides an on-ramp to evaluate and iterate on WPD.

Testing:
ninja check-all
large internal services at Meta that links against native binaries runs correctly with WPD enabled

[tejohnson]

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

Also, isn't this hiding possibly necessary info from WPD that might be needed for correct class hierarchy analysis affecting other IR modules? I.e. in the type-metadata-skip-vtable-filepaths.cpp test, what if A was derived from a struct B, which was also defined/used in another module without this skipping option. We would lose information about the override of f in A, and possibly do an incorrect devirtualization elsewhere. It seems like a dangerous option to provide.

It might be better to provide an option that can somehow mark vtables in a given module as unsafe for devirt, and propagate that info to WPD.

[modimo]

In D152741#4418831, @tejohnson wrote:

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

For our third-party libraries, they're pre-built into native files by GCC so that's unfortunately not an option.

Also, isn't this hiding possibly necessary info from WPD that might be needed for correct class hierarchy analysis affecting other IR modules? I.e. in the type-metadata-skip-vtable-filepaths.cpp test, what if A was derived from a struct B, which was also defined/used in another module without this skipping option. We would lose information about the override of f in A, and possibly do an incorrect devirtualization elsewhere. It seems like a dangerous option to provide.

It might be better to provide an option that can somehow mark vtables in a given module as unsafe for devirt, and propagate that info to WPD.

That would nicely side-step mismatched flags. Public vcall_visibility describes this case but with --lto-whole-program-visibility there's no a distinction between Public because of deferred vs. Public because the type is known unsafe. Thoughts on an unsafe vcall_visibility to capture the latter notion?

[tejohnson]

In D152741#4419265, @modimo wrote:

In D152741#4418831, @tejohnson wrote:

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

For our third-party libraries, they're pre-built into native files by GCC so that's unfortunately not an option.

I'm confused - how would you pass this new option then? I was assuming you were passing this option to some LLVM built files at the interface of those libraries. In which case not passing -flto-unit and -fwhole-program-visibility should have a similar effect (suppress the type metadata).

Also, isn't this hiding possibly necessary info from WPD that might be needed for correct class hierarchy analysis affecting other IR modules? I.e. in the type-metadata-skip-vtable-filepaths.cpp test, what if A was derived from a struct B, which was also defined/used in another module without this skipping option. We would lose information about the override of f in A, and possibly do an incorrect devirtualization elsewhere. It seems like a dangerous option to provide.

It might be better to provide an option that can somehow mark vtables in a given module as unsafe for devirt, and propagate that info to WPD.

That would nicely side-step mismatched flags. Public vcall_visibility describes this case but with --lto-whole-program-visibility there's no a distinction between Public because of deferred vs. Public because the type is known unsafe. Thoughts on an unsafe vcall_visibility to capture the latter notion?

That would be better I think. Maybe "unknown".

[modimo]

In D152741#4419324, @tejohnson wrote:

In D152741#4419265, @modimo wrote:

In D152741#4418831, @tejohnson wrote:

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

For our third-party libraries, they're pre-built into native files by GCC so that's unfortunately not an option.

I'm confused - how would you pass this new option then? I was assuming you were passing this option to some LLVM built files at the interface of those libraries. In which case not passing -flto-unit and -fwhole-program-visibility should have a similar effect (suppress the type metadata).

Oh I see, I misunderstood. Yes this is being passed to LLVM built files. We want to avoid manual allowlists/blocklists because code changes make it less flexible and scalable than an automatic option. This can also be pretty tricky to do correctly since we can get type metadata from multiple TUs and all of them would need to be opted out for WPD to not kick in.

Also, isn't this hiding possibly necessary info from WPD that might be needed for correct class hierarchy analysis affecting other IR modules? I.e. in the type-metadata-skip-vtable-filepaths.cpp test, what if A was derived from a struct B, which was also defined/used in another module without this skipping option. We would lose information about the override of f in A, and possibly do an incorrect devirtualization elsewhere. It seems like a dangerous option to provide.

It might be better to provide an option that can somehow mark vtables in a given module as unsafe for devirt, and propagate that info to WPD.

That would nicely side-step mismatched flags. Public vcall_visibility describes this case but with --lto-whole-program-visibility there's no a distinction between Public because of deferred vs. Public because the type is known unsafe. Thoughts on an unsafe vcall_visibility to capture the latter notion?

That would be better I think. Maybe "unknown".

Sounds good, I'll rework the patch.

[modimo]

Implement using VCallVisibilityUnknown

[modimo]

Remove unrelated change, fix typo

[tejohnson]

In D152741#4419366, @modimo wrote:

In D152741#4419324, @tejohnson wrote:

In D152741#4419265, @modimo wrote:

In D152741#4418831, @tejohnson wrote:

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

For our third-party libraries, they're pre-built into native files by GCC so that's unfortunately not an option.

I'm confused - how would you pass this new option then? I was assuming you were passing this option to some LLVM built files at the interface of those libraries. In which case not passing -flto-unit and -fwhole-program-visibility should have a similar effect (suppress the type metadata).

Oh I see, I misunderstood. Yes this is being passed to LLVM built files. We want to avoid manual allowlists/blocklists because code changes make it less flexible and scalable than an automatic option.

It seems like you need allowlists or blocklists in either case - either it is passed as a regex via the option proposed here, or the build system modifies the options for that set of files.

This can also be pretty tricky to do correctly since we can get type metadata from multiple TUs and all of them would need to be opted out for WPD to not kick in.

But clang is presumably compiling a single TU at a time, so your regex needs to cover them all anyway? I'm not sure I understand the distinction between doing something like -fskip-vtable-filepaths=third-party/.* vs something like applying -funknown-vtable-visibility to each third-party/*.cc compile.

I really think the logic for which files to apply this option to belongs in the build system, not in the clang driver - just like any other clang option. It isn't clear to me why this particular option should be applied based on a file regex.

I like the approach of communicating this via vcall visibility, but just think that it should be applied to the current TU whenever a TBD new option is provided.

[modimo]

In D152741#4421067, @tejohnson wrote:

In D152741#4419366, @modimo wrote:

In D152741#4419324, @tejohnson wrote:

In D152741#4419265, @modimo wrote:

In D152741#4418831, @tejohnson wrote:

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

For our third-party libraries, they're pre-built into native files by GCC so that's unfortunately not an option.

I'm confused - how would you pass this new option then? I was assuming you were passing this option to some LLVM built files at the interface of those libraries. In which case not passing -flto-unit and -fwhole-program-visibility should have a similar effect (suppress the type metadata).

Oh I see, I misunderstood. Yes this is being passed to LLVM built files. We want to avoid manual allowlists/blocklists because code changes make it less flexible and scalable than an automatic option.

It seems like you need allowlists or blocklists in either case - either it is passed as a regex via the option proposed here, or the build system modifies the options for that set of files.

This can also be pretty tricky to do correctly since we can get type metadata from multiple TUs and all of them would need to be opted out for WPD to not kick in.

But clang is presumably compiling a single TU at a time, so your regex needs to cover them all anyway? I'm not sure I understand the distinction between doing something like -fskip-vtable-filepaths=third-party/.* vs something like applying -funknown-vtable-visibility to each third-party/*.cc compile.

The blocklists need to be enforced on internal files that interact with native libraries and those live in many different areas:

; /third-party/include/boost.h

class A {}

; /internal-source/a.cpp
#include "boost.h"

class B : public A

; /third-party/lib/boost.a
#include "boost.h"

class C : public A

That being said, this is something the build system can detect and mark.

I really think the logic for which files to apply this option to belongs in the build system, not in the clang driver - just like any other clang option. It isn't clear to me why this particular option should be applied based on a file regex.

The big advantage of doing this in the FE is that we know which types are actually coming from the native headers. Blocking all types in the TU is overly conservative and also less stable as header changes can effectively turn on/off unrelated large chunks of WPD.

[modimo]

Remove leftover code from original implementation

[tejohnson]

In D152741#4422462, @modimo wrote:

In D152741#4421067, @tejohnson wrote:

In D152741#4419366, @modimo wrote:

In D152741#4419324, @tejohnson wrote:

In D152741#4419265, @modimo wrote:

In D152741#4418831, @tejohnson wrote:

I think I understand the motivation, but not sure I agree this is the right approach - can you simply not pass -flto-unit and -fwhole-program-vtables for these files?

For our third-party libraries, they're pre-built into native files by GCC so that's unfortunately not an option.

I'm confused - how would you pass this new option then? I was assuming you were passing this option to some LLVM built files at the interface of those libraries. In which case not passing -flto-unit and -fwhole-program-visibility should have a similar effect (suppress the type metadata).

Oh I see, I misunderstood. Yes this is being passed to LLVM built files. We want to avoid manual allowlists/blocklists because code changes make it less flexible and scalable than an automatic option.

It seems like you need allowlists or blocklists in either case - either it is passed as a regex via the option proposed here, or the build system modifies the options for that set of files.

This can also be pretty tricky to do correctly since we can get type metadata from multiple TUs and all of them would need to be opted out for WPD to not kick in.

But clang is presumably compiling a single TU at a time, so your regex needs to cover them all anyway? I'm not sure I understand the distinction between doing something like -fskip-vtable-filepaths=third-party/.* vs something like applying -funknown-vtable-visibility to each third-party/*.cc compile.

The blocklists need to be enforced on internal files that interact with native libraries and those live in many different areas:

; /third-party/include/boost.h

class A {}

; /internal-source/a.cpp
#include "boost.h"

class B : public A

; /third-party/lib/boost.a
#include "boost.h"

class C : public A

That being said, this is something the build system can detect and mark.

I really think the logic for which files to apply this option to belongs in the build system, not in the clang driver - just like any other clang option. It isn't clear to me why this particular option should be applied based on a file regex.

The big advantage of doing this in the FE is that we know which types are actually coming from the native headers. Blocking all types in the TU is overly conservative and also less stable as header changes can effectively turn on/off unrelated large chunks of WPD.

Ok what I missed is that you don't want to apply this to entire TUs, but rather just some paths that are header files, which may be included in many source files. So in your above example, you really only need to apply to the path of third-party/include/boost.h - is that correct? That would mark class A, and therefore anything derived from it won't get devirtualized. I guess in your example above, you are trying to prevent the devirtualization in a.cpp since there are hidden overrides (class C) in boost.a native objects.

The example included with the patch applies the option to the source file of the test case, and therefore its entire TU. It would be helpful to have a test case structured like your example above, where the file path is just that of the header.

Maybe a better option name is something like -funknown-vtable-visibility-filepaths= ? It seems a bit more descriptive.

[modimo]

In D152741#4438007, @tejohnson wrote:

Ok what I missed is that you don't want to apply this to entire TUs, but rather just some paths that are header files, which may be included in many source files. So in your above example, you really only need to apply to the path of third-party/include/boost.h - is that correct?

Yep!

That would mark class A, and therefore anything derived from it won't get devirtualized. I guess in your example above, you are trying to prevent the devirtualization in a.cpp since there are hidden overrides (class C) in boost.a native objects.

Exactly, we saw this scenario causing issues when enabling WPD.

The example included with the patch applies the option to the source file of the test case, and therefore its entire TU. It would be helpful to have a test case structured like your example above, where the file path is just that of the header.

Makes sense and yeah the test case is confusing. Changed it to apply to just the header file.

Maybe a better option name is something like -funknown-vtable-visibility-filepaths= ? It seems a bit more descriptive.

Sure, changed.

[modimo]

Address feedback. Allow empty string to unset the flag

[tejohnson]

lgtm

[wenlei]

The big advantage of doing this in the FE is that we know which types are actually coming from the native headers. Blocking all types in the TU is overly conservative and also less stable as header changes can effectively turn on/off unrelated large chunks of WPD.

This is clearly going to be selective in punting unsafe devirt, however do you have data comparing the effectiveness of the two (module granularity vs header granularity)?

I also think introducing unknown visibility is a good idea for this to work, but this is going to be exposed to users (not hidden implementing only), so we would probably need to have spec/rule to handle conflicting visibility from different source and make those explicit here: https://clang.llvm.org/docs/LTOVisibility.html.

There's a spectrum of solutions we could use to make WPD safer, but we need to be careful not to make this whole thing too convoluted with multiple solutions implemented, but little differentiation in their incremental value (extra perf, extra safety). So having concrete data backing the incremental value of this solution would be helpful.

clang/include/clang/Basic/CodeGenOptions.h

191

Pattern string doesn't seem to be used anywhere, can we simplify this using llvm::Regex instead of RegexWithPattern?

198

update comment

clang/include/clang/Driver/Options.td

3223

nit: filepaths -> filepath - this does not accept a comma separated list of paths(regexs).

3224

Pass empty string to unset

Remove this to be concise?

clang/lib/Frontend/CompilerInvocation.cpp

2001

rename err_drv_optimization_remark_pattern so it's not specific to remarks.

llvm/include/llvm/IR/GlobalObject.h

41

This probably needs doc change too: https://clang.llvm.org/docs/LTOVisibility.html.

We also need to define when flag derived visibility conflicts with attribute derived visibility, what is the priority order.

[modimo]

In D152741#4445112, @wenlei wrote:

The big advantage of doing this in the FE is that we know which types are actually coming from the native headers. Blocking all types in the TU is overly conservative and also less stable as header changes can effectively turn on/off unrelated large chunks of WPD.

This is clearly going to be selective in punting unsafe devirt, however do you have data comparing the effectiveness of the two (module granularity vs header granularity)?

Some data would help quantify the difference, I'll hack up a module granularity implementation and compare to the current one.

I also think introducing unknown visibility is a good idea for this to work, but this is going to be exposed to users (not hidden implementing only), so we would probably need to have spec/rule to handle conflicting visibility from different source and make those explicit here: https://clang.llvm.org/docs/LTOVisibility.html.

The ordering for conflicts is embedded in the logic for CodeGenModule::GetVCallVisibilityLevel which has priority order of:

1. Unknown
2. Public
3. LinkageUnit
4. TranslationUnit

I'll update the documentation to reflect this.

There's a spectrum of solutions we could use to make WPD safer, but we need to be careful not to make this whole thing too convoluted with multiple solutions implemented, but little differentiation in their incremental value (extra perf, extra safety). So having concrete data backing the incremental value of this solution would be helpful.

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?

clang/include/clang/Basic/CodeGenOptions.h

191

It's used here in CompilerInvocation.cpp:

if (Opts.SkipVtableFilepaths.hasValidPattern())
  GenerateArg(Args, OPT_funknown_vtable_visibility_filepaths_EQ,
              Opts.SkipVtableFilepaths.Pattern, SA);

[modimo]

Feedback, add documentation for flag and unknown visibility, rebase.

[wenlei]

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.

[modimo]

In D152741#4445807, @wenlei wrote:

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.

On a large Meta service with manually opting in an internal source folder with -fwhole-program-vtables there's 2,933 single implementation methods that get devirtualized. Using -funknown-vtable-visibility-filepath on the same service for the third-party directory there's 32,800 single implementation method devirts.

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.

That complexity already exists with -fvisibility=hidden interacting with __attribute__((visibility("..."))) where the most conservative annotation wins out. Having a type annotated with unknown visibility is just adding a more conservative option than public.

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.

My current prototype RTTI implementation doesn't really need an unknown visibility because it's generating and passing a blocklist at symbol resolution time. For FatObj, the input into WPD is identical to when everything is built with ThinLTO so unknown isn't that valuable either. The original intent was to use this to roll out WPD to select services but performance-wise opting in folders with -fwhole-program-vtables proves just as effective without having to modify LLVM. With that use case gone, there's no longer a need on my side for this change. Others may find value for this in the interim to on-board/evaluate WPD but that's not very concrete value.

clang/docs/LTOVisibility.rst

 Classes that fall into either of these categories can be marked up with the
 ``[[clang::lto_visibility_public]]`` attribute. To specifically handle the
 COM case, classes with the ``__declspec(uuid())`` attribute receive public
 LTO visibility. On Windows platforms, clang-cl's ``/MT`` and ``/MTd``
 flags statically link the program against a prebuilt standard library;
 these flags imply public LTO visibility for every class declared in the
 ``std`` and ``stdext`` namespaces.
 
+Additionally ``-funknown-vtable-visibility-filepath=<regex>`` can be passed
+to mark all classes defined in files matching the pattern as unknown LTO
+visibility. This visibility level indicates the class is known to be unsafe
+to optimize (e.g. having derived classes outside the LTO Unit) and guarantees
+they are not optimized under any circumnstances. Filepath based exclusion is
+helpful when known header files (e.g third-party/.*) define classes that
+can be referenced outside of the LTO Unit.
+
+When visibility information comes from multiple sources the most conservative
+visibility will be used. Thus, unknown will take precedence over public and
+public will take precedence over hidden.
+
 Example
 =======
 
 The following example shows how LTO visibility works in practice in several
 cases involving two linkage units, ``main`` and ``dso.so``.
 
 .. code-block:: none
 

clang/include/clang/Basic/CodeGenOptions.h

public:
   std::string CoverageNotesFile;
 
   /// Regexes separated by a semi-colon to filter the files to instrument.
   std::string ProfileFilterFiles;
 
   /// Regexes separated by a semi-colon to filter the files to not instrument.
   std::string ProfileExcludeFiles;
 
+  /// Regular expression with its original pattern string
+  struct RegexWithPattern {
+    std::string Pattern;
+    std::shared_ptr<llvm::Regex> Regex;
+
+    RegexWithPattern() = default;
+    RegexWithPattern(std::string Pattern, std::shared_ptr<llvm::Regex> Regex)
+        : Pattern(Pattern), Regex(Regex) {}
+
+    /// Returns true iff the argument holds a valid regular
+    /// expression.
+    bool hasValidPattern() const { return Regex != nullptr; }
+
+    /// Matches the given string against the regex, if there is some.
+    bool patternMatches(StringRef String) const {
+      return hasValidPattern() && Regex->match(String);
+    }
+  };
+
+  /// Skip types defined in these paths when performing whole-program vtable
+  /// optimization.
+  RegexWithPattern SkipVtableFilepaths;
+
   /// The version string to put into coverage files.
   char CoverageVersion[4];
 
   /// Enable additional debugging information.
   std::string DebugPass;
 
   /// The string to embed in debug information as the current working directory.
   std::string DebugCompilationDir;

clang/include/clang/Basic/DiagnosticDriverKinds.td

def err_drv_unknown_objc_runtime : Error<
   "unknown or ill-formed Objective-C runtime '%0'">;
 def err_drv_invalid_cf_runtime_abi
   : Error<"invalid CoreFoundation Runtime ABI '%0'; must be one of "
           "'objc', 'standalone', 'swift', 'swift-5.0', 'swift-4.2', 'swift-4.1'">;
 def err_drv_gnustep_objc_runtime_incompatible_binary : Error<
   "GNUstep Objective-C runtime version %0 incompatible with target binary format">;
 def err_drv_emit_llvm_link : Error<
    "-emit-llvm cannot be used when linking">;
-def err_drv_optimization_remark_pattern : Error<
+def err_drv_regex_pattern : Error<
   "in pattern '%1': %0">;
 def err_drv_optimization_remark_format : Error<
   "unknown remark serializer format: '%0'">;
 def err_drv_no_neon_modifier : Error<"[no]neon is not accepted as modifier, please use [no]simd instead">;
 def err_drv_invalid_omp_target : Error<"OpenMP target is invalid: '%0'">;
 def err_drv_incompatible_omp_arch : Error<"OpenMP target architecture '%0' pointer size is incompatible with host '%1'">;
 def err_drv_omp_host_ir_file_not_found : Error<
   "provided host compiler IR file '%0' is required to generate code for OpenMP "

clang/include/clang/Driver/Options.td

defm new_infallible : BoolFOption<"new-infallible",
   LangOpts<"NewInfallible">, DefaultFalse,
   PosFlag<SetTrue, [], "Enable">, NegFlag<SetFalse, [], "Disable">,
   BothFlags<[CC1Option], " treating throwing global C++ operator new as always returning valid memory "
   "(annotates with __attribute__((returns_nonnull)) and throw()). This is detectable in source.">>;
 defm whole_program_vtables : BoolFOption<"whole-program-vtables",
   CodeGenOpts<"WholeProgramVTables">, DefaultFalse,
   PosFlag<SetTrue, [CC1Option], "Enables whole-program vtable optimization. Requires -flto">,
   NegFlag<SetFalse>, BothFlags<[CoreOption]>>;
+def funknown_vtable_visibility_filepath_EQ : Joined<["-"], "funknown-vtable-visibility-filepath=">, Group<f_Group>,
+  HelpText<"Skip types from participating in whole-program vtable optimization defined under this filepath regex.">,
+  Flags<[CC1Option]>;
 defm split_lto_unit : BoolFOption<"split-lto-unit",
   CodeGenOpts<"EnableSplitLTOUnit">, DefaultFalse,
   PosFlag<SetTrue, [CC1Option], "Enables splitting of the LTO unit">,
   NegFlag<SetFalse>, BothFlags<[CoreOption]>>;
 defm force_emit_vtables : BoolFOption<"force-emit-vtables",
   CodeGenOpts<"ForceEmitVTables">, DefaultFalse,
   PosFlag<SetTrue, [CC1Option], "Emits more virtual tables to improve devirtualization">,
   NegFlag<SetFalse>, BothFlags<[CoreOption]>>,

clang/lib/CodeGen/CGVTables.cpp

bool CodeGenModule::HasHiddenLTOVisibility(const CXXRecordDecl *RD) {
 
   if (!getTriple().isOSBinFormatCOFF() &&
       LV.getVisibility() != HiddenVisibility)
     return false;
 
   return !AlwaysHasLTOVisibilityPublic(RD);
 }
 
+bool CodeGenModule::HasUnknownLTOVisibility(const CXXRecordDecl *RD) {
+  if (CodeGenOpts.SkipVtableFilepaths.hasValidPattern()) {
+    const PresumedLoc &PLoc =
+        Context.getFullLoc(RD->getBeginLoc()).getPresumedLoc(true);
+    assert(PLoc.isValid() && "Source location is expected to be always valid.");
+    std::string FilePath = PLoc.getFilename();
+
+    if (CodeGenOpts.SkipVtableFilepaths.patternMatches(FilePath))
+      return true;
+  }
+  return false;
+}
+
+static llvm::GlobalObject::VCallVisibility
+getMinVCallVisibility(llvm::GlobalObject::VCallVisibility TypeVisA,
+                      llvm::GlobalObject::VCallVisibility TypeVisB) {
+  if (TypeVisA == llvm::GlobalObject::VCallVisibilityUnknown ||
+      TypeVisB == llvm::GlobalObject::VCallVisibilityUnknown)
+    return llvm::GlobalObject::VCallVisibilityUnknown;
+
+  return std::min(TypeVisA, TypeVisB);
+}
+
 llvm::GlobalObject::VCallVisibility CodeGenModule::GetVCallVisibilityLevel(
     const CXXRecordDecl *RD, llvm::DenseSet<const CXXRecordDecl *> &Visited) {
   // If we have already visited this RD (which means this is a recursive call
   // since the initial call should have an empty Visited set), return the max
   // visibility. The recursive calls below compute the min between the result
   // of the recursive call and the current TypeVis, so returning the max here
   // ensures that it will have no effect on the current TypeVis.
   if (!Visited.insert(RD).second)
     return llvm::GlobalObject::VCallVisibilityTranslationUnit;
 
   LinkageInfo LV = RD->getLinkageAndVisibility();
   llvm::GlobalObject::VCallVisibility TypeVis;
-  if (!isExternallyVisible(LV.getLinkage()))
+  if (HasUnknownLTOVisibility(RD))
+    TypeVis = llvm::GlobalObject::VCallVisibilityUnknown;
+  else if (!isExternallyVisible(LV.getLinkage()))
     TypeVis = llvm::GlobalObject::VCallVisibilityTranslationUnit;
   else if (HasHiddenLTOVisibility(RD))
     TypeVis = llvm::GlobalObject::VCallVisibilityLinkageUnit;
   else
     TypeVis = llvm::GlobalObject::VCallVisibilityPublic;
 
   for (const auto &B : RD->bases())
     if (B.getType()->getAsCXXRecordDecl()->isDynamicClass())
-      TypeVis = std::min(
+      TypeVis = getMinVCallVisibility(
           TypeVis,
           GetVCallVisibilityLevel(B.getType()->getAsCXXRecordDecl(), Visited));
 
   for (const auto &B : RD->vbases())
     if (B.getType()->getAsCXXRecordDecl()->isDynamicClass())
-      TypeVis = std::min(
+      TypeVis = getMinVCallVisibility(
           TypeVis,
           GetVCallVisibilityLevel(B.getType()->getAsCXXRecordDecl(), Visited));
 
   return TypeVis;
 }
 
 void CodeGenModule::EmitVTableTypeMetadata(const CXXRecordDecl *RD,
                                            llvm::GlobalVariable *VTable,

clang/lib/CodeGen/CodeGenAction.cpp

static void reportOptRecordError(Error E, DiagnosticsEngine &Diags,
                                    const CodeGenOptions &CodeGenOpts) {
     handleAllErrors(
         std::move(E),
       [&](const LLVMRemarkSetupFileError &E) {
           Diags.Report(diag::err_cannot_open_file)
               << CodeGenOpts.OptRecordFile << E.message();
         },
       [&](const LLVMRemarkSetupPatternError &E) {
-          Diags.Report(diag::err_drv_optimization_remark_pattern)
+          Diags.Report(diag::err_drv_regex_pattern)
               << E.message() << CodeGenOpts.OptRecordPasses;
         },
       [&](const LLVMRemarkSetupFormatError &E) {
           Diags.Report(diag::err_drv_optimization_remark_format)
               << CodeGenOpts.OptRecordFormat;
         });
     }
 

clang/lib/CodeGen/CodeGenModule.h

public:
   /// Return the alignment specified in an allocate directive, if present.
   std::optional<CharUnits> getOMPAllocateAlignment(const VarDecl *VD);
 
   /// Returns whether the given record has hidden LTO visibility and therefore
   /// may participate in (single-module) CFI and whole-program vtable
   /// optimization.
   bool HasHiddenLTOVisibility(const CXXRecordDecl *RD);
 
+  /// Returns whether the given record has unknown LTO visibility and therefore
+  /// should never participate in (single-module) CFI and whole-program vtable
+  /// optimization.
+  bool HasUnknownLTOVisibility(const CXXRecordDecl *RD);
+
   /// Returns whether the given record has public LTO visibility (regardless of
   /// -lto-whole-program-visibility) and therefore may not participate in
   /// (single-module) CFI and whole-program vtable optimization.
   bool AlwaysHasLTOVisibilityPublic(const CXXRecordDecl *RD);
 
   /// Returns the vcall visibility of the given type. This is the scope in which
   /// a virtual function call could be made which ends up being dispatched to a
   /// member function of this class. This scope can be wider than the visibility

clang/lib/Driver/ToolChains/Clang.cpp

bool SplitLTOUnit =
       Args.hasFlag(options::OPT_fsplit_lto_unit,
                    options::OPT_fno_split_lto_unit, DefaultsSplitLTOUnit);
   if (SanitizeArgs.needsLTO() && !SplitLTOUnit)
     D.Diag(diag::err_drv_argument_not_allowed_with) << "-fno-split-lto-unit"
                                                     << "-fsanitize=cfi";
   if (SplitLTOUnit)
     CmdArgs.push_back("-fsplit-lto-unit");
 
+  if (const Arg *A = Args.getLastArg(
+          options::OPT_funknown_vtable_visibility_filepath_EQ)) {
+    StringRef Path = A->getValue();
+    if (!Path.empty()) {
+      if (!WholeProgramVTables)
+        D.Diag(diag::err_drv_argument_only_allowed_with)
+            << "-funknown-vtable-visibility-filepath"
+            << "-fwhole-program-vtables";
+      CmdArgs.push_back(
+          Args.MakeArgString("-funknown-vtable-visibility-filepath=" + Path));
+    }
+    A->claim();
+  }
+
   if (Arg *A = Args.getLastArg(options::OPT_fglobal_isel,
                                options::OPT_fno_global_isel)) {
     CmdArgs.push_back("-mllvm");
     if (A->getOption().matches(options::OPT_fglobal_isel)) {
       CmdArgs.push_back("-global-isel=1");
 
       // GISel is on by default on AArch64 -O0, so don't bother adding
       // the fallback remarks for it. Other combinations will add a warning of

clang/lib/Frontend/CompilerInvocation.cpp

ParseOptimizationRemark(DiagnosticsEngine &Diags, ArgList &Args,
 
   auto InitializeResultPattern = [&Diags, &Args, &Result](const Arg *A,
                                                           StringRef Pattern) {
     Result.Pattern = Pattern.str();
 
     std::string RegexError;
     Result.Regex = std::make_shared<llvm::Regex>(Result.Pattern);
     if (!Result.Regex->isValid(RegexError)) {
-      Diags.Report(diag::err_drv_optimization_remark_pattern)
+      Diags.Report(diag::err_drv_regex_pattern)
           << RegexError << A->getAsString(Args);
       return false;
     }
 
     return true;
   };
 
   for (Arg *A : Args) {
GenerateOptimizationRemark(Args, SA, OPT_Rpass_EQ, "pass",
                              Opts.OptimizationRemark);
 
   GenerateOptimizationRemark(Args, SA, OPT_Rpass_missed_EQ, "pass-missed",
                              Opts.OptimizationRemarkMissed);
 
   GenerateOptimizationRemark(Args, SA, OPT_Rpass_analysis_EQ, "pass-analysis",
                              Opts.OptimizationRemarkAnalysis);
 
+  if (Opts.SkipVtableFilepaths.hasValidPattern())
+    GenerateArg(Args, OPT_funknown_vtable_visibility_filepath_EQ,
+                Opts.SkipVtableFilepaths.Pattern, SA);
+
   GenerateArg(Args, OPT_fdiagnostics_hotness_threshold_EQ,
               Opts.DiagnosticsHotnessThreshold
                   ? Twine(*Opts.DiagnosticsHotnessThreshold)
                   : "auto",
               SA);
 
   GenerateArg(Args, OPT_fdiagnostics_misexpect_tolerance_EQ,
               Twine(*Opts.DiagnosticsMisExpectTolerance), SA);
#undef CODEGEN_OPTION_WITH_MARSHALLING
 
   Opts.OptimizationRemarkAnalysis = ParseOptimizationRemark(
       Diags, Args, OPT_Rpass_analysis_EQ, "pass-analysis");
 
   NeedLocTracking |= Opts.OptimizationRemark.hasValidPattern() ||
                      Opts.OptimizationRemarkMissed.hasValidPattern() ||
                      Opts.OptimizationRemarkAnalysis.hasValidPattern();
 
+  if (Arg *A = Args.getLastArg(OPT_funknown_vtable_visibility_filepath_EQ)) {
+    StringRef Val = A->getValue();
+    std::string RegexError;
+    std::shared_ptr<llvm::Regex> Pattern = std::make_shared<llvm::Regex>(Val);
+    if (!Pattern->isValid(RegexError)) {
+      Diags.Report(diag::err_drv_regex_pattern)
+          << RegexError << A->getAsString(Args);
+      Pattern.reset();
+    }
+    Opts.SkipVtableFilepaths =
+        CodeGenOptions::RegexWithPattern(std::string(Val), Pattern);
+  }
+
   bool UsingSampleProfile = !Opts.SampleProfileFile.empty();
   bool UsingProfile =
       UsingSampleProfile || !Opts.ProfileInstrumentUsePath.empty();
 
   if (Opts.DiagnosticsWithHotness && !UsingProfile &&
       // An IR file will contain PGO as metadata
       IK.getLanguage() != Language::LLVM_IR)
     Diags.Report(diag::warn_drv_diagnostics_hotness_requires_pgo)

clang/test/CodeGenCXX/type-metadata-unknown-vtable-visibility-filepath.cpp

+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -flto=thin -flto-unit -fwhole-program-vtables -triple x86_64-unknown-linux -fvisibility=hidden -emit-llvm -o - a.cpp | FileCheck %s
+// RUN: %clang_cc1 -flto=thin -flto-unit -fwhole-program-vtables -triple x86_64-unknown-linux -funknown-vtable-visibility-filepath=h$ -fvisibility=hidden -emit-llvm -o - a.cpp | FileCheck -check-prefix=SKIP-PATH %s
+
+// CHECK-DAG: gv: (name: "_ZTV1A", {{.*}} vcall_visibility: 1
+// CHECK-DAG: gv: (name: "_ZTV1B", {{.*}} vcall_visibility: 1
+
+// Check that unknown visibility only applies to type from header file.
+// SKIP-PATH-DAG: gv: (name: "_ZTV1A", {{.*}} vcall_visibility: 3
+// SKIP-PATH-DAG: gv: (name: "_ZTV1B", {{.*}} vcall_visibility: 1
+
+//--- a.h
+struct A {
+  virtual int f() { return 1; }
+};
+
+//--- a.cpp
+#include "a.h"
+
+struct B {
+  virtual int f() { return 1; }
+};
+
+int f() {
+  auto a = new A();
+  return a->f();
+}
+
+int f1() {
+  auto b = new B();
+  return b->f();
+}

clang/test/Driver/funknown-vtable-visibility-filepath.c

+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin 2>&1 | FileCheck --check-prefix=NOSKIP %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -fwhole-program-vtables -funknown-vtable-visibility-filepath=abc 2>&1 | FileCheck --check-prefix=SKIP %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -fwhole-program-vtables -funknown-vtable-visibility-filepath=abc -funknown-vtable-visibility-filepath= 2>&1 | FileCheck --check-prefix=NOSKIP %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -funknown-vtable-visibility-filepath=abc 2>&1 | FileCheck --check-prefix=ERROR1 %s
+// RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin -funknown-vtable-visibility-filepath=abc -funknown-vtable-visibility-filepath= 2>&1 | FileCheck --check-prefix=NOSKIP %s
+
+// SKIP: "-funknown-vtable-visibility-filepath=abc"
+// NOSKIP-NOT: "-funknown-vtable-visibility-filepath=abc"
+// ERROR1: error: invalid argument '-funknown-vtable-visibility-filepath' only allowed with '-fwhole-program-vtables'

llvm/include/llvm/IR/GlobalObject.h

public:
   enum VCallVisibility {
     // Type is potentially visible to external code.
     VCallVisibilityPublic = 0,
     // Type is only visible to code which will be in the current Module after
     // LTO internalization.
     VCallVisibilityLinkageUnit = 1,
     // Type is only visible to code in the current Module.
     VCallVisibilityTranslationUnit = 2,
+    // Type is unknown and should always be treated conservatively.
+    VCallVisibilityUnknown = 3,
   };
 
 protected:
   GlobalObject(Type *Ty, ValueTy VTy, Use *Ops, unsigned NumOps,
                LinkageTypes Linkage, const Twine &Name,
                unsigned AddressSpace = 0)
       : GlobalValue(Ty, VTy, Ops, NumOps, Linkage, Name, AddressSpace) {
     setGlobalValueSubClassData(0);

llvm/lib/IR/Metadata.cpp

addMetadata(LLVMContext::MD_vcall_visibility,
                                Type::getInt64Ty(getContext()), Visibility))}));
 }
 
 GlobalObject::VCallVisibility GlobalObject::getVCallVisibility() const {
   if (MDNode *MD = getMetadata(LLVMContext::MD_vcall_visibility)) {
     uint64_t Val = cast<ConstantInt>(
                        cast<ConstantAsMetadata>(MD->getOperand(0))->getValue())
                        ->getZExtValue();
-    assert(Val <= 2 && "unknown vcall visibility!");
+    assert(Val <= 3 && "unknown vcall visibility!");
     return (VCallVisibility)Val;
   }
   return VCallVisibility::VCallVisibilityPublic;
 }
 
 void Function::setSubprogram(DISubprogram *SP) {
   setMetadata(LLVMContext::MD_dbg, SP);
 }

llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp

bool DevirtModule::tryFindVirtualCallTargets(
     std::vector<VirtualCallTarget> &TargetsForSlot,
     const std::set<TypeMemberInfo> &TypeMemberInfos, uint64_t ByteOffset,
     ModuleSummaryIndex *ExportSummary) {
   for (const TypeMemberInfo &TM : TypeMemberInfos) {
     if (!TM.Bits->GV->isConstant())
       return false;
 
     // We cannot perform whole program devirtualization analysis on a vtable
-    // with public LTO visibility.
+    // with public or unknown LTO visibility.
     if (TM.Bits->GV->getVCallVisibility() ==
-        GlobalObject::VCallVisibilityPublic)
+            GlobalObject::VCallVisibilityPublic ||
+        TM.Bits->GV->getVCallVisibility() ==
+            GlobalObject::VCallVisibilityUnknown)
       return false;
 
     Constant *Ptr = getPointerAtOffset(TM.Bits->GV->getInitializer(),
                                        TM.Offset + ByteOffset, M);
     if (!Ptr)
       return false;
 
     auto C = Ptr->stripPointerCasts();
for (const auto &S : P.VTableVI.getSummaryList()) {
           // to treat this case conservatively (in case the bitcode is old).
           // However, we will also not have any vtable functions in the
           // case of a pure virtual base class. In that case we do want
           // to set VS to avoid treating it conservatively.
           !GlobalValue::isAvailableExternallyLinkage(S->linkage())) {
         VS = CurVS;
         // We cannot perform whole program devirtualization analysis on a vtable
         // with public LTO visibility.
-        if (VS->getVCallVisibility() == GlobalObject::VCallVisibilityPublic)
+        if (VS->getVCallVisibility() == GlobalObject::VCallVisibilityPublic ||
+            VS->getVCallVisibility() == GlobalObject::VCallVisibilityUnknown)
           return false;
       }
     }
     // There will be no VS if all copies are available_externally having no
     // type metadata. In that case we can't safely perform WPD.
     if (!VS)
       return false;
     if (!VS->isLive())

llvm/test/ThinLTO/X86/devirt.ll

 ; RUN: llvm-lto2 run %t2.o -save-temps -pass-remarks=. \
 ; RUN:   -whole-program-visibility \
 ; RUN:   -o %t3 \
 ; RUN:   -r=%t2.o,test,px \
 ; RUN:   -r=%t2.o,_ZN1A1nEi,p \
 ; RUN:   -r=%t2.o,_ZN1B1fEi,p \
 ; RUN:   -r=%t2.o,_ZN1C1fEi,p \
 ; RUN:   -r=%t2.o,_ZN1D1mEi,p \
+; RUN:   -r=%t2.o,_ZN1E1nEi,p \
 ; RUN:   -r=%t2.o,_ZTV1B,px \
 ; RUN:   -r=%t2.o,_ZTV1C,px \
-; RUN:   -r=%t2.o,_ZTV1D,px 2>&1 | FileCheck %s --check-prefix=REMARK
+; RUN:   -r=%t2.o,_ZTV1D,px \
+; RUN:   -r=%t2.o,_ZTV1F,px 2>&1 | FileCheck %s --check-prefix=REMARK
 ; RUN: llvm-dis %t3.1.4.opt.bc -o - | FileCheck %s --check-prefix=CHECK-IR
 
 ; Check that we're able to prevent specific function from being
 ; devirtualized when running index based WPD.
 ; RUN: llvm-lto2 run %t2.o -save-temps -pass-remarks=. \
 ; RUN:   -whole-program-visibility \
 ; RUN:   -wholeprogramdevirt-skip=_ZN1A1nEi \
 ; RUN:   -o %t3 \
 ; RUN:   -r=%t2.o,test,px \
 ; RUN:   -r=%t2.o,_ZN1A1nEi,p \
 ; RUN:   -r=%t2.o,_ZN1B1fEi,p \
 ; RUN:   -r=%t2.o,_ZN1C1fEi,p \
 ; RUN:   -r=%t2.o,_ZN1D1mEi,p \
+; RUN:   -r=%t2.o,_ZN1E1nEi,p \
 ; RUN:   -r=%t2.o,_ZTV1B,px \
 ; RUN:   -r=%t2.o,_ZTV1C,px \
-; RUN:   -r=%t2.o,_ZTV1D,px 2>&1 | FileCheck %s --check-prefix=SKIP
+; RUN:   -r=%t2.o,_ZTV1D,px \
+; RUN:   -r=%t2.o,_ZTV1F,px 2>&1 | FileCheck %s --check-prefix=SKIP
 
 ; RUN: llvm-lto2 run %t.o -save-temps -pass-remarks=. \
 ; RUN:   -whole-program-visibility \
 ; RUN:   -o %t3 \
 ; RUN:   -r=%t.o,test,px \
 ; RUN:   -r=%t.o,_ZN1A1nEi,p \
 ; RUN:   -r=%t.o,_ZN1B1fEi,p \
 ; RUN:   -r=%t.o,_ZN1C1fEi,p \
 ; RUN:   -r=%t.o,_ZN1D1mEi,p \
+; RUN:   -r=%t.o,_ZN1E1nEi,p \
 ; RUN:   -r=%t.o,_ZTV1B, \
 ; RUN:   -r=%t.o,_ZTV1C, \
 ; RUN:   -r=%t.o,_ZTV1D, \
+; RUN:   -r=%t.o,_ZTV1F, \
 ; RUN:   -r=%t.o,_ZN1A1nEi, \
 ; RUN:   -r=%t.o,_ZN1B1fEi, \
 ; RUN:   -r=%t.o,_ZN1C1fEi, \
 ; RUN:   -r=%t.o,_ZN1D1mEi, \
+; RUN:   -r=%t.o,_ZN1E1nEi, \
 ; RUN:   -r=%t.o,_ZTV1B,px \
 ; RUN:   -r=%t.o,_ZTV1C,px \
-; RUN:   -r=%t.o,_ZTV1D,px 2>&1 | FileCheck %s --check-prefix=REMARK --dump-input=fail
+; RUN:   -r=%t.o,_ZTV1D,px \
+; RUN:   -r=%t.o,_ZTV1F,px 2>&1 | FileCheck %s --check-prefix=REMARK --dump-input=fail
 ; RUN: llvm-dis %t3.1.4.opt.bc -o - | FileCheck %s --check-prefix=CHECK-IR
 
 ; REMARK-DAG: single-impl: devirtualized a call to _ZN1A1nEi
 ; REMARK-DAG: single-impl: devirtualized a call to _ZN1D1mEi
 
 ; SKIP-NOT: devirtualized a call to _ZN1A1nEi
 
 target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-grtev4-linux-gnu"
 
 %struct.A = type { ptr }
 %struct.B = type { %struct.A }
 %struct.C = type { %struct.A }
 %struct.D = type { ptr }
 
+%struct.E = type { ptr }
+%struct.F = type { %struct.E }
+
 @_ZTV1B = constant { [4 x ptr] } { [4 x ptr] [ptr null, ptr undef, ptr @_ZN1B1fEi, ptr @_ZN1A1nEi] }, !type !0, !type !1
 @_ZTV1C = constant { [4 x ptr] } { [4 x ptr] [ptr null, ptr undef, ptr @_ZN1C1fEi, ptr @_ZN1A1nEi] }, !type !0, !type !2
 @_ZTV1D = constant { [3 x ptr] } { [3 x ptr] [ptr null, ptr undef, ptr @_ZN1D1mEi] }, !type !3
 
+@_ZTV1F = constant { [3 x ptr] } { [3 x ptr] [ptr null, ptr undef, ptr @_ZN1E1nEi] }, !type !5, !vcall_visibility !6
+
 
 ; CHECK-IR-LABEL: define i32 @test
-define i32 @test(ptr %obj, ptr %obj2, i32 %a) {
+define i32 @test(ptr %obj, ptr %obj2, ptr %obj3, i32 %a) {
 entry:
   %vtable = load ptr, ptr %obj
   %p = call i1 @llvm.type.test(ptr %vtable, metadata !"_ZTS1A")
   call void @llvm.assume(i1 %p)
   %fptrptr = getelementptr ptr, ptr %vtable, i32 1
   %fptr1 = load ptr, ptr %fptrptr, align 8
 
   ; Check that the call was devirtualized.
   ; CHECK-IR: %call = tail call i32 @_ZN1A1nEi
   ; Ensure !prof and !callees metadata for indirect call promotion removed.
   ; CHECK-IR-NOT: prof
   ; CHECK-IR-NOT: callees
-  %call = tail call i32 %fptr1(ptr nonnull %obj, i32 %a), !prof !5, !callees !6
+  %call = tail call i32 %fptr1(ptr nonnull %obj, i32 %a), !prof !7, !callees !8
 
   %fptr22 = load ptr, ptr %vtable, align 8
 
   ; We still have to call it as virtual.
   ; CHECK-IR: %call3 = tail call i32 %fptr22
   %call3 = tail call i32 %fptr22(ptr nonnull %obj, i32 %call)
 
   %vtable2 = load ptr, ptr %obj2
   %p2 = call i1 @llvm.type.test(ptr %vtable2, metadata !4)
   call void @llvm.assume(i1 %p2)
 
   %fptr33 = load ptr, ptr %vtable2, align 8
 
   ; Check that the call was devirtualized.
   ; CHECK-IR: %call4 = tail call i32 @_ZN1D1mEi
   %call4 = tail call i32 %fptr33(ptr nonnull %obj2, i32 %call3)
-  ret i32 %call4
+
+  %vtable1 = load ptr, ptr %obj3
+  %p3 = call i1 @llvm.type.test(ptr %vtable1, metadata !"_ZTS1E")
+  call void @llvm.assume(i1 %p3)
+  %fptrptr1 = getelementptr ptr, ptr %vtable1, i32 0
+  %fptr44 = load ptr, ptr %fptrptr1, align 8
+
+  ; Check that the call was not devirtualized because of "unknown"
+  ; vcall_visibility.
+  ; CHECK-IR: %call5 = tail call i32 %fptr44
+  %call5 = tail call i32 %fptr44(ptr nonnull %obj, i32 %call4)
+  ret i32 %call5
 }
 ; CHECK-IR-LABEL: ret i32
 ; CHECK-IR-LABEL: }
 
 declare i1 @llvm.type.test(ptr, metadata)
 declare void @llvm.assume(i1)
 
 define i32 @_ZN1B1fEi(ptr %this, i32 %a) #0 {
    ret i32 0;
 }
 
 define i32 @_ZN1A1nEi(ptr %this, i32 %a) #0 {
    ret i32 0;
 }
 
 define i32 @_ZN1C1fEi(ptr %this, i32 %a) #0 {
    ret i32 0;
 }
 
 define i32 @_ZN1D1mEi(ptr %this, i32 %a) #0 {
    ret i32 0;
 }
 
+define i32 @_ZN1E1nEi(ptr %this, i32 %a) #0 {
+   ret i32 0;
+}
+
 ; Make sure we don't inline or otherwise optimize out the direct calls.
 attributes #0 = { noinline optnone }
 
 !0 = !{i64 16, !"_ZTS1A"}
 !1 = !{i64 16, !"_ZTS1B"}
 !2 = !{i64 16, !"_ZTS1C"}
 !3 = !{i64 16, !4}
 !4 = distinct !{}
-!5 = !{!"VP", i32 0, i64 1, i64 1621563287929432257, i64 1}
-!6 = !{ptr @_ZN1A1nEi}
+!5 = !{i64 16, !"_ZTS1E"}
+!6 = !{i64 3}
+!7 = !{!"VP", i32 0, i64 1, i64 1621563287929432257, i64 1}
+!8 = !{ptr @_ZN1A1nEi}