David Blaikie via llvm-dev
2021-Oct-19 01:54 UTC
[llvm-dev] [EXTERNAL] Re: Question about -flto behavior
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>
Mehdi AMINI via llvm-dev
2021-Oct-19 02:53 UTC
[llvm-dev] [EXTERNAL] Re: Question about -flto behavior
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/22b8ead4/attachment.html>