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

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.

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<mailto: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<mailto: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/74b2f2bf/attachment.html>

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>

On Mon, Oct 18, 2021 at 3:55 PM Snider, Todd via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
I guess this approach gives flexibility to the build at the cost of extra
compile time to go through the whole optimization pipeline including code
generation potentially unnecessarily. Normally in LLVM we don't go through
code generation during an -flto -S or -c compile, and only part of the
optimization pipeline.

>
> 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.
>
Note you can emit the final machine code when building with -flto and
linking with lld via -Wl,--lto-emit-asm, in which case the a.out or
specified output file will contain assembly instead of ELF.

Teresa

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

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211026/b439b40f/attachment.html>