This adds a -fthinlto-index= option to clang-cl, which allows it to
be used to drive ThinLTO backend passes. This allows clang-cl to be
used for distributed ThinLTO.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This is similar to r254927 for the clang driver, and reuses the tests from that commit for the backend part. On the frontend, it differs in that clang-cl does not support -x (per the comment in clang/lib/Driver/Driver.cpp line 2068: "// No driver mode exposes -x and /TC or /TP; we don't support mixing them.") Instead of requiring -x ir, the behavior added to clang-cl here is to expect that what would be detected as a native object file based on file extension is really a bitcode file. If it isn't, the backend will cause us to say "error: Invalid bitcode signature", which I think is adequate as a diagnostic.
Do we really need to support clang-cl syntax here? Can't the user of -fthinlto-index= use the regular clang driver?
I think it depends on how many compiler flags we have to pass to backend compilation actions. I don't have a good sense of how many of those actually matter. Some flags affect the object file and are not encoded in bitcode, like -ffunction-sections. It's potentially onerous for a build system to have to work out for itself that cl -O2 implicitly enables -Gy, which is the MSVC spelling of -ffunction-sections, so therefore we need this other set of backend action flags. It seems nicer to for the build system to just take the first stage command line and re-run it with a new input and this new flag.
If we want to make the behavior consistent, I would say we should port this new -x ir behavior over to clang so it's the same as clang-cl.
Do we really need to support clang-cl syntax here? Can't the user of -fthinlto-index= use the regular clang driver?
We could, of course, require using the clang driver for this feature. But I would argue that clang-cl exists to make it easy for projects that use MSVC-style command lines to switch to Clang and get access to the benefits it provides, including features for which there is no equivalent MSVC flag. So I think this is reasonable to add.
LGTM, but please wait for @pcc to make sure he is satisfied.
I think it would be good to port the file type deduction to clang (possibly as a follow on), to make these consistent.
I think it's a little unfortunate that we're continuing to go down the road of letting users pass more flags to the ThinLTO backend action, but I won't stand in the way here.