[llvm-dev] [EXTERNAL] Re: Question about -flto behavior

[David Blaikie via llvm-dev]

sure, possibly, if you've got that technology/decide to write out the IR in
assembler directives in some form?

On Mon, Oct 18, 2021 at 7:53 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

> On Mon, Oct 18, 2021 at 6:55 PM David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Mon, Oct 18, 2021 at 3:55 PM Snider, Todd <t-snider at ti.com> wrote:
>>
>>>
>>>
>>> David,
>>>
>>>
>>>
>>> Thanks for the reply. That makes sense.
>>>
>>>
>>>
>>> A couple of further thoughts … In the LTO implementation that I am
>>> working on, when -flto is specified to the compiler, the compiler embeds
>>> the IR in the compiler generated object file. The linker can then read the
>>> IR out of the incoming object file if LTO is enabled at link time or just
>>> ignore the IR if LTO is disabled at link time.
>>>
>>
>> Fair enough - in that case, I guess you might want your compiler to
>> generate both? It could generate x.ll for the LLVM IR and x.s for the
>> machine assembly.
>>
>
> It seems to me that such a compiler should generate an assembly file that
> contains the assembly as well the IR blob in a single file (that can be
> piped into the assembler)?
>
>
>>
>>
>>>  I would agree that having -S write out the IR content for -flto
>>> provides a good way to see what is being fed into the LTO link in a human
>>> readable form.
>>>
>>>
>>>
>>> For our LTO implementation, the linker can be told to keep the IR that
>>> it extracts from the incoming object files. You can then run llvm-dis over
>>> the extracted IR to see the .ll version.
>>>
>>>
>>>
>>> ~ Todd
>>>
>>>
>>>
>>> *From:* David Blaikie <dblaikie at gmail.com>
>>> *Sent:* Monday, October 18, 2021 4:21 PM
>>> *To:* Snider, Todd <t-snider at ti.com>
>>> *Cc:* llvm-dev at lists.llvm.org
>>> *Subject:* [EXTERNAL] Re: [llvm-dev] Question about -flto behavior
>>>
>>>
>>>
>>> Yeah, sounds expected to me - flto produces object files that aren't
>>> really object files - instead they're LLVM IR (bitcode) that the linker
>>> identifies, then calls back into LLVM to link the IR, optimize on that IR,
>>> then produce object code/assembly/whatever).
>>>
>>> So the "assembly" form of an "object" (really LLVM bitcode) file is LLVM
>>> textual IR.
>>>
>>>
>>>
>>> On Mon, Oct 18, 2021 at 1:56 PM Snider, Todd via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> Hi All,
>>>
>>>
>>>
>>> When -flto is combined with -S on the clang command line, the output .s
>>> file contains IR content instead of target assembly language.
>>>
>>>
>>>
>>> Is this expected/correct behavior? I was anticipating that the output .s
>>> file would contain target assembly code.
>>>
>>>
>>>
>>> ~ Todd Snider
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211018/74141765/attachment.html>