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

[Mehdi Amini via llvm-commits]

> On Feb 3, 2017, at 10:21 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote:
> 
>> 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
> sync.

+1, that was also my original concern.

> 
>> 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.

Yes, that’d be closer to what clang is doing with save-temps. 

I tried to emit both ASM and object at the same time in the past, but the MC layer really does not like that. Jim told that it would be a major redesign to achieve it (cleanly).

Best,

— 
Mehdi