llvm dev - Aug 2016 - [LTO] Bypass the integrated assembler ...

> On Aug 9, 2016, at 9:24 AM, Kevin Choi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> -Wl,--plugin=LLVMgold.so,--plugin-opt=emit-llvm
This is totally Gold specific. The fact that he mentions using LTOCodeGenerator
makes me think that he does not use Gold.
> 
> http://llvm.org/docs/CommandGuide/opt.html
<http://llvm.org/docs/CommandGuide/opt.html>
> http://llvm.org/docs/CommandGuide/llc.html
<http://llvm.org/docs/CommandGuide/llc.html>
> 
> "The llc command compiles LLVM source inputs into assembly language
for a specified architecture."
> 
> On 9 August 2016 at 04:16, Umesh Kalappa via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi Guys ,
> 
> We enabled the LTO on our code base and found that LTO uses the
> integrated/builtin assembler to emit the final optimized code .O
> (FileType= CGFT_ObjectFile) .
> 
> Can we bypass this semantic ,for something like you emit .S  file
> (FileType=CGFT_AssemblyFile),
> 
> Then we pass this  .S file to our native assembler and  the linker
> .....any switch/ options  do so ?
> 
> i.e  something like as we have   "-no-integrated-as" for clang
driver .
> 
> Currently ,we thought of hacking the LTOCodeGenerator.cpp for the same .
> 
> The bottom-line is that ,we need to use our native assembler ,not the
builtin .
> 
> Any thoughts on this ?
Unfortunately there is no “ready-to-use” way, clang has a driver that can dump
intermediate file (here the .s) and invoke a chain of commands. The linker
plugin is not designed this way, it is invoked by the linker and given the input
bitcode will produce one or multiple object files for the linker.
What you want to do could be achieved by hacking the LTOCodeGenerator and do
something like use posix_spawn and pipes to invoke your assembler.
Otherwise you can also do something like what Kevin had in mind: ask
LTOCodeGenerator to produce the bitcode before the backend and exit the linker
process at this point, then run llc on it to get the assembly, assemble it, and
re-invoke the linker. This is probably less convenient if you need to integrate
with a build system.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160809/1f9de679/attachment.html>

Otherwise you can also do something like what Kevin had in mind: ask
LTOCodeGenerator to produce the bitcode before the backend and exit the linker
process at this point, then run llc on it to get the assembly, assemble it, and
re-invoke the linker.
Or feed the emitted bitcode back into clang, without –flto, which would let you
use all the normal clang ways to decide what kind of output you want. (Clang
will accept .bc or .ll files as input.)  This also has the support advantage of
not introducing developer tools into your application build workflow; whether
this is important to you depends on who your users are and what tools you
normally deliver to them.  (llc is generally not considered a tool appropriate
to end-users.)
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi
Amini via llvm-dev
Sent: Tuesday, August 09, 2016 9:53 AM
To: Kevin Choi
Cc: LLVM Developers Mailing List
Subject: Re: [llvm-dev] [LTO] Bypass the integrated assembler ...


On Aug 9, 2016, at 9:24 AM, Kevin Choi via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

-Wl,--plugin=LLVMgold.so,--plugin-opt=emit-llvm

This is totally Gold specific. The fact that he mentions using LTOCodeGenerator
makes me think that he does not use Gold.



http://llvm.org/docs/CommandGuide/opt.html
http://llvm.org/docs/CommandGuide/llc.html

"The llc command compiles LLVM source inputs into assembly language for a
specified architecture."

On 9 August 2016 at 04:16, Umesh Kalappa via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi Guys ,

We enabled the LTO on our code base and found that LTO uses the
integrated/builtin assembler to emit the final optimized code .O
(FileType= CGFT_ObjectFile) .

Can we bypass this semantic ,for something like you emit .S  file
(FileType=CGFT_AssemblyFile),

Then we pass this  .S file to our native assembler and  the linker
.....any switch/ options  do so ?

i.e  something like as we have   "-no-integrated-as" for clang driver
.

Currently ,we thought of hacking the LTOCodeGenerator.cpp for the same .

The bottom-line is that ,we need to use our native assembler ,not the builtin .

Any thoughts on this ?

Unfortunately there is no “ready-to-use” way, clang has a driver that can dump
intermediate file (here the .s) and invoke a chain of commands. The linker
plugin is not designed this way, it is invoked by the linker and given the input
bitcode will produce one or multiple object files for the linker.
What you want to do could be achieved by hacking the LTOCodeGenerator and do
something like use posix_spawn and pipes to invoke your assembler.
Otherwise you can also do something like what Kevin had in mind: ask
LTOCodeGenerator to produce the bitcode before the backend and exit the linker
process at this point, then run llc on it to get the assembly, assemble it, and
re-invoke the linker. This is probably less convenient if you need to integrate
with a build system.

—
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160810/e59d3f0b/attachment.html>

> On Aug 9, 2016, at 8:17 PM, Robinson, Paul <paul.robinson at
sony.com> wrote:
> 
> Otherwise you can also do something like what Kevin had in mind: ask
LTOCodeGenerator to produce the bitcode before the backend and exit the linker
process at this point, then run llc on it to get the assembly, assemble it, and
re-invoke the linker.
> Or feed the emitted bitcode back into clang, without –flto, which would let
you use all the normal clang ways to decide what kind of output you want. (Clang
will accept .bc or .ll files as input.)  This also has the support advantage of
not introducing developer tools into your application build workflow; whether
this is important to you depends on who your users are and what tools you
normally deliver to them.  (llc is generally not considered a tool appropriate
to end-users.) <>
Very good point indeed.

— 
Mehdi

 
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Mehdi Amini via llvm-dev
> Sent: Tuesday, August 09, 2016 9:53 AM
> To: Kevin Choi
> Cc: LLVM Developers Mailing List
> Subject: Re: [llvm-dev] [LTO] Bypass the integrated assembler ...
>  
>  
> On Aug 9, 2016, at 9:24 AM, Kevin Choi via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>  
> -Wl,--plugin=LLVMgold.so,--plugin-opt=emit-llvm
>  
> This is totally Gold specific. The fact that he mentions using
LTOCodeGenerator makes me think that he does not use Gold.
> 
> 
> 
> http://llvm.org/docs/CommandGuide/opt.html
<http://llvm.org/docs/CommandGuide/opt.html>
> http://llvm.org/docs/CommandGuide/llc.html
<http://llvm.org/docs/CommandGuide/llc.html>
> 
> "The llc command compiles LLVM source inputs into assembly language
for a specified architecture."
>  
> On 9 August 2016 at 04:16, Umesh Kalappa via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi Guys ,
> 
> We enabled the LTO on our code base and found that LTO uses the
> integrated/builtin assembler to emit the final optimized code .O
> (FileType= CGFT_ObjectFile) .
> 
> Can we bypass this semantic ,for something like you emit .S  file
> (FileType=CGFT_AssemblyFile),
> 
> Then we pass this  .S file to our native assembler and  the linker
> .....any switch/ options  do so ?
> 
> i.e  something like as we have   "-no-integrated-as" for clang
driver .
> 
> Currently ,we thought of hacking the LTOCodeGenerator.cpp for the same .
> 
> The bottom-line is that ,we need to use our native assembler ,not the
builtin .
> 
> Any thoughts on this ?
>  
> Unfortunately there is no “ready-to-use” way, clang has a driver that can
dump intermediate file (here the .s) and invoke a chain of commands. The linker
plugin is not designed this way, it is invoked by the linker and given the input
bitcode will produce one or multiple object files for the linker.
> What you want to do could be achieved by hacking the LTOCodeGenerator and
do something like use posix_spawn and pipes to invoke your assembler.
> Otherwise you can also do something like what Kevin had in mind: ask
LTOCodeGenerator to produce the bitcode before the backend and exit the linker
process at this point, then run llc on it to get the assembly, assemble it, and
re-invoke the linker. This is probably less convenient if you need to integrate
with a build system.
>  
> — 
> Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160809/304eb653/attachment.html>