We noticed that when invoking the thinBackend via clang (for the
distributed build case) that flags like -ffunction-sections and
-emit-llvm were not having the intended effect. This could have been
fixed by setting up the TargetOptions and the CodeGenFileType in the LTO
Config, but since clang already has handling for all of this, it is
straightforward to just let it do the handling (just below the
early return after runThinLTOBackend being removed here).
Depends on D31100.
I just noticed that EmitAssembly does a lot more than just emission - it is also setting up an optimization pipeline in CreatePasses, which we don't want to do in the ThinLTO backend case as we already do the opt in LTO. Which makes me think that the simplest and most consistent solution, especially if as in discussed in D31114 we'll be using the LTO API for emitting object and assembly code, is to use LTO for all file emission in the ThinLTO backend case. It would mean extending lto::Config to be able to flag when we want to emit-llvm or emit-llvm-bc, and invoke the appropriate module writer/printer instead of normal codegen. That way -emit-llvm* will always get output corresponding to the native object/assembly in the ThinLTO backend case. WDYT?