Page MenuHomePhabricator

[ThinLTO] Use clang's existing code gen handling for ThinLTO backends

Authored by tejohnson on Mar 17 2017, 2:02 PM.



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.

Event Timeline

tejohnson created this revision.Mar 17 2017, 2:02 PM
tejohnson updated this revision to Diff 92324.Mar 20 2017, 7:32 AM

As discussed in the review threads for D31114 and D31100, only fall
back to clang's output file emission for -emit-llvm and -emit-llvm-bc.

tejohnson added inline comments.Mar 20 2017, 11:27 AM

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?

tejohnson added inline comments.Mar 30 2017, 1:37 PM

I have a new patch set that will do just this that I am uploading momentarily

tejohnson updated this revision to Diff 93535.Mar 30 2017, 1:39 PM

Use LTO to emit LLVM IR

tejohnson abandoned this revision.Mar 31 2017, 6:56 AM

Subsumed by D31534