[PATCH] D29475: [LTO] Add ability to emit assembly to new LTO API

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 3 10:21:08 PST 2017

> I agree about the need for an assembler 'driver' in the linker to make this
> work and the potential fragility. This is what we have and it's worked fine on
> our side with the previous LTO API. Note that clang's non-LTO -save-temps flow
> calls the assembler separately (via clang -cc1as), too. It's perfectly doable
> to ensure that the linker is called with the correct options to pass through to
> the assembler when clang is used as the driver for LTO.

Note that clang calls itself, so it is trivial to keep the commands in

> I like Rafael's idea of using the MC layer to emit both assembly and an object
> at the same time with the same settings (if that's what you're proposing) - we
> could use that for the non-LTO flow in clang too. I haven't checked how easy
> that would be, but it's perhaps worth considering in the future.

I was actually suggesting producing the .s file and then using MC, from
the lib/LTO, to produce the .o.


More information about the llvm-commits mailing list