[llvm-dev] ThinLTO: passing TargetOptions to LLVMgold.so

[Teresa Johnson via llvm-dev]

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>