Our ThinLTO testing was inoperative for a while, and now that it's running
again, we're seeing the linker step reporting "Expected a single module."
Note that our linker is using the C API to read bitcode.
It looks like the ThinLTO writer now emits two modules, but AFAICT most of
the APIs in BitcodeReader.cpp expect to see only one. Is this just an
oversight in supporting ThinLTO from the C API?
I am a little bemused because I had thought Apple's "ld64" also used the
C API and supported ThinLTO.
Any help/guidance/tips welcome (other than "switch to the C++ API").
The current C LTO API wraps a legacy C++ implementation of the LTO API, which does not support multi-module bitcode files, and we do not intend to teach it to do so. We planned to replace the old API with a new C API that wraps the new resolution-based C++ API, but that hasn’t happened yet.
Mehdi was working on the new C API here: https://reviews.llvm.org/D31898
I’m not sure if he will have time to finish it, though.
To deal with Apple’s linker the clang driver passes a flag to the frontend on Darwin which prevents it from creating multi-module bitcode files.
Thanks Peter! I think PS4 will have to follow what Darwin does here, at least for now.
I assume the new API would consume old-format bitcode with no problem, if we decide to make that conversion and still want to read old-style bitcode files.
That’s correct. With the old-format bitcode a couple of features won’t work with ThinLTO (i.e. control flow integrity and whole-program devirtualization), but presumably you aren’t already using them.