[PATCH] D33870: Expose IRMover flag

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

In https://reviews.llvm.org/D33870#774277, @eschew wrote:

> I'm almost certain the bug was in my frontend's misuse of LLVM's linking infrastructure, not a bug in linking itself (per se).
>
> My frontend first constructs a shell Module with declarations for the language's runtime functions, then codegens into the shell, then links the shell with the runtime. It was constructing the shell from a precompiled bitcode by iterating over the runtime's Module and calling shell->getOrInsertFunction(...) providing *a type from the runtime Module*.  I'm guessing mixing types like that between modules isn't kosher. The workaround/fix is to round-trip the constructed shell through bitcode.
>
> What I'm confused about is: what does the OnlyNamed flag (in TypeFinder.cpp) actually do, from the perspective of LLVM IR?


I'm not familiar with the TypeFinder, but I did a little bit of digging. As you noted earlier, the change of this flag from true to false recently was a fix by Mehdi for ThinLTO IR linking (r287453 - [ThinLTO] Fix crash when importing an opaque type). Looks like we need to eagerly map all types because of complications due to the fact that we are only linking some of the symbols. But it sounds like you couldn't reproduce the original problem with the test case in that change?

There are 2 other callers with OnlyNamed=false:

1. the AsmPrinter calls this with OnlyNamed=false because it is printing all the types.
2. StripTypeNames in IPO/StripSymbols.cpp, and that code is actually looking for named types, and skips those without names! So I am not sure why it needs to call TypeFinder with OnlyNamed=false to start with.


Repository:
  rL LLVM

https://reviews.llvm.org/D33870