Johan Engelen via llvm-dev
2016-Oct-05 10:20 UTC
[llvm-dev] ThinLTO: passing TargetOptions to LLVMgold.so
Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We currently don't emit some of them in the IR, but I see that Clang does, so perhaps we should just mimic that. But some other options are not expressed in IR (e.g. FunctionSections, relocation model). I see that I can pass LLVM options to the plugin, so one way is to pass all non-default options as plugin-opt cmdline flags. I can't find code in Clang that does that though. Thanks for your advice, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161005/32d819df/attachment.html>
Teresa Johnson via llvm-dev
2016-Oct-05 13:16 UTC
[llvm-dev] ThinLTO: passing TargetOptions to LLVMgold.so
Hi Johan, For things that can be passed via the IR, that's the best way to go. For other things, I have run into some similar issues. For example, I have a patch out to pass -ffunction-sections and -fdata-sections to the plugin-opt via clang (D24644). There was also a patch proposed by someone else to pass -mllvm internal options to the plugin, which I would also like, but there was disagreement on doing this (D20423). But this is a good general question. There are probably other options as you are finding that are typically passed to clang that really need to go to the plugin in the case of ThinLTO (and regular LTO) in order to have an effect. I'm curious to see if others have an opinion on the best way to handle this. Teresa On Wed, Oct 5, 2016 at 3:20 AM, Johan Engelen <jbc.engelen at gmail.com> wrote:> Hi all, > I am trying to figure out the best way to deal with non-default > TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm > adding support for ThinLTO to the LDC D compiler) > > Things like the target triple, target CPU and target CPU features, some > floating point options like unsafe-fp-math, etc., those are (or can be > made) explicit in the IR. Is that the way to go? We currently don't emit > some of them in the IR, but I see that Clang does, so perhaps we should > just mimic that. > But some other options are not expressed in IR (e.g. FunctionSections, > relocation model). > I see that I can pass LLVM options to the plugin, so one way is to pass > all non-default options as plugin-opt cmdline flags. I can't find code in > Clang that does that though. > > Thanks for your advice, > Johan > > > >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161005/495b38a0/attachment.html>
Mehdi Amini via llvm-dev
2016-Oct-05 15:44 UTC
[llvm-dev] ThinLTO: passing TargetOptions to LLVMgold.so
> On Oct 5, 2016, at 3:20 AM, Johan Engelen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) > > Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We currently don't emit some of them in the IR, but I see that Clang does, so perhaps we should just mimic that.Yes, definitely.> But some other options are not expressed in IR (e.g. FunctionSections, relocation model). > I see that I can pass LLVM options to the plugin, so one way is to pass all non-default options as plugin-opt cmdline flags. I can't find code in Clang that does that though.The usual model is that the linker interacts with the LTO codegen to pass these options. Assuming you’d link a program on MacOS with ThinLTO for instance, the linker will derive the “pic model” the following way: https://github.com/Apple-FOSS-Mirror/ld64/blob/master/src/ld/parsers/lto_file.cpp#L594 (not the call to ::lto_codegen_set_pic_model). — Mehdi
Johan Engelen via llvm-dev
2016-Oct-06 09:01 UTC
[llvm-dev] ThinLTO: passing TargetOptions to LLVMgold.so
On Wed, Oct 5, 2016 at 5:44 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:> > > > But some other options are not expressed in IR (e.g. FunctionSections, > relocation model). > > I see that I can pass LLVM options to the plugin, so one way is to pass > all non-default options as plugin-opt cmdline flags. I can't find code in > Clang that does that though. > > The usual model is that the linker interacts with the LTO codegen to pass > these options. >My question is: how does the linker know what to tell the LTO codegen? ;)> Assuming you’d link a program on MacOS with ThinLTO for instance, the > linker will derive the “pic model” the following way: > https://github.com/Apple-FOSS-Mirror/ld64/blob/master/src/ > ld/parsers/lto_file.cpp#L594 (not the call to > ::lto_codegen_set_pic_model). >Thanks a lot for the pointer. (didn't even realize that `ld64` source is so easily available) This lead me to where `ld64` receives the options, so I can browse through that to see what it accepts (it accepts `-mllvm` so that's nice). -Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161006/4de1d3e6/attachment.html>
Reasonably Related Threads
- [ThinLTO] static library failure with object files with the same name
- [ThinLTO] static library failure with object files with the same name
- [ThinLTO] static library failure with object files with the same name
- [ThinLTO] static library failure with object files with the same name
- [ThinLTO] static library failure with object files with the same name