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

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 18 18:54:39 PDT 2021


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.


>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211018/7189aa8c/attachment.html>


More information about the llvm-dev mailing list