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
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
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).
> 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
Well the linker knows some stuff on what it is linking. In the link I sent:
- The first if depends a dynamic library or an executable
- The second branch is triggered by “-static" on the command line.
- The last one is the architecture we’re linking for.
All the -mllvm options are really not intended to be a stable interface though.