getting gold plugin to work?

Attached is the start of a patch to make the gold plugin work on
Darwin for use as a cross-compiler. There needs to be a build step
somewhere in llvm-gcc that copies it into libexec/<gcc

/libLLVMgold.so, but I've been doing that manually for now.

It doesn't seem that simple use of -O4 results in the plugin learning
what subtarget is desired. I presume that the llvm-gcc driver needs to
pass -mcpu down through collect2 into ld somehow. Has anybody solved
this already? Perhaps we should finally just put the feature string
into the bitcode?

deep

gold-plugin-darwin-cross.diff (446 Bytes)

Attached is the start of a patch to make the gold plugin work on
Darwin for use as a cross-compiler.

Nice. I checked that it still builds correctly on linux. I think it is
fine, but Nick should probably have a look.

There needs to be a build step
somewhere in llvm-gcc that copies it into libexec/<gcc
>/libLLVMgold.so, but I've been doing that manually for now.

Yes, this is bad. The problem is that we build the plugin in llvm, not
llvm-gcc. Another option is to add a new search directory to llvm-gcc.
That way you could configure llvm-gcc with a --gold-plugin-dir=<path>
and the resulting binary would search there. This would work nicely
when using an already installed llvm copy.

It doesn't seem that simple use of -O4 results in the plugin learning
what subtarget is desired. I presume that the llvm-gcc driver needs to
pass -mcpu down through collect2 into ld somehow. Has anybody solved
this already? Perhaps we should finally just put the feature string
into the bitcode?

Interesting. It is probably better to pass it via the command line. I
will try to take a look at it. Do you have a small testcase?

deep

Thanks,

There needs to be a build step
somewhere in llvm-gcc that copies it into libexec/<gcc
>/libLLVMgold.so, but I've been doing that manually for now.

Yes, this is bad. The problem is that we build the plugin in llvm, not
llvm-gcc. Another option is to add a new search directory to llvm-gcc.
That way you could configure llvm-gcc with a --gold-plugin-dir=<path>
and the resulting binary would search there. This would work nicely
when using an already installed llvm copy.

That would work for gold, but what about nm, etc.?

It doesn't seem that simple use of -O4 results in the plugin learning
what subtarget is desired. I presume that the llvm-gcc driver needs to
pass -mcpu down through collect2 into ld somehow. Has anybody solved
this already? Perhaps we should finally just put the feature string
into the bitcode?

Interesting. It is probably better to pass it via the command line. I
will try to take a look at it. Do you have a small testcase?

I have no idea how to reduce this.

Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8
--with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the
bitcode will be "armv7-eabi" but the actual CPU subtarget won't be
known to the gold plugin. I'd think the same would be true for any
cross-compiler. Note that self-hosting X86 will eventually use a CPUID
instruction to determine the proper subtarget on the fly so it will
usually be correct.

deep

That would work for gold, but what about nm, etc.?

You would still need to copy it :frowning:

I have no idea how to reduce this.

Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8
--with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the
bitcode will be "armv7-eabi" but the actual CPU subtarget won't be
known to the gold plugin. I'd think the same would be true for any
cross-compiler. Note that self-hosting X86 will eventually use a CPUID
instruction to determine the proper subtarget on the fly so it will
usually be correct.

I will try to take a look, but it will take some time.

deep

Cheers,

If we can decide the way we want the options passed, I can take a stab
at it (or more likely Viktor will).

I'd expect that gold will need an option that tells it that some
following option or options are to be passed to the plugin. The plugin
API will need to pass these flags down. Any suggestions here that
would be compatible with the FSF view of the universe would be
welcome.

I assume the plugin's options should be either the existing cl::opt
ones (-mcpu, etc.) or similar to the llc ones.

deep

If we can decide the way we want the options passed, I can take a stab
at it (or more likely Viktor will).

The linker has a -plugin-opt option. You probably do something like

-fplugin-opt=-mcpu=

I'd expect that gold will need an option that tells it that some
following option or options are to be passed to the plugin. The plugin
API will need to pass these flags down. Any suggestions here that
would be compatible with the FSF view of the universe would be
welcome.

On the gcc plugin we just reexec gcc, so the plugin options are gcc
options. Not sure if there is much to be gained here since the two
plugins are independent.

I assume the plugin's options should be either the existing cl::opt
ones (-mcpu, etc.) or similar to the llc ones.

You are free to name it, but using something similar to a llc option
is probably a good idea.

deep

Cheers,

I'd expect that gold will need an option that tells it that some
following option or options are to be passed to the plugin. The plugin
API will need to pass these flags down.

This is already in place. Linker command line options could look like

-plugin pathname [ -plugin-opt arg1 ] [ -plugin-opt arg2 ] ...

gold will load plug-in by pathname and pass to it the arguments arg1, arg2, etc. in the same order in which they appear on the command line.

-Viktor

If we can decide the way we want the options passed, I can take a stab
at it (or more likely Viktor will).

The linker has a -plugin-opt option. You probably do something like

-fplugin-opt=-mcpu=

...

I assume the plugin's options should be either the existing cl::opt
ones (-mcpu, etc.) or similar to the llc ones.

You are free to name it, but using something similar to a llc option
is probably a good idea.

LINK_COMMAND_SPEC in gcc.c will need to change to add:
    %{O*:-plugin-opt=-O%*} \
    %{w:-plugin-opt=-w} \
    %{f*:-plugin-opt=-f%*} \
    ${m*:-plugin-opt=-m%*} \

and then the plugin will need to have an argument translation process
similar to llvm-gcc's LLVM_SET_TARGET_OPTIONS,
LLVM_SET_MACHINE_OPTIONS, and LLVM_SET_SUBTARGET_FEATURES as well as
all the logic in llvm-backend.cpp for translating options. I don't see
any way to unify this logic with the llvm-gcc logic because llvm-gcc's
decisions are derived from global state instead of a direct argument
translation process. Yuck.

Opinions welcome.

deep

Rafael Espindola wrote:

If we can decide the way we want the options passed, I can take a stab
at it (or more likely Viktor will).

The linker has a -plugin-opt option. You probably do something like

-fplugin-opt=-mcpu=

The gold plugin has its own option list, it doesn't pass options through to LLVM -- which come to think of it would probably be a really good idea. Adding a call to "cl::ParseCommandLineOptions" for the unknown options would be a good change to have.

Nick

Sandeep Patel wrote:

Attached is the start of a patch to make the gold plugin work on
Darwin for use as a cross-compiler. There needs to be a build step
somewhere in llvm-gcc that copies it into libexec/<gcc
>/libLLVMgold.so, but I've been doing that manually for now.

With this patch, it seems that it produces a file named LLVMgold.so instead of libLLVMgold.so. Any ideas?

I'll look into it later if you're not sure why, but that's the only thing blocking committing it.

It doesn't seem that simple use of -O4 results in the plugin learning
what subtarget is desired. I presume that the llvm-gcc driver needs to
pass -mcpu down through collect2 into ld somehow. Has anybody solved
this already? Perhaps we should finally just put the feature string
into the bitcode?

That's not all. -disable-fp-elim will be dropped, for example. The libLTO generated code assumes -mcpu=native, -march=native, frame pointers eliminated, etc. This should all be flag controlled but nobody's bothered to do it yet.

Nick

Sandeep Patel wrote:

Attached is the start of a patch to make the gold plugin work on
Darwin for use as a cross-compiler. There needs to be a build step
somewhere in llvm-gcc that copies it into libexec/<gcc
>/libLLVMgold.so, but I've been doing that manually for now.

With this patch, it seems that it produces a file named LLVMgold.so instead
of libLLVMgold.so. Any ideas?

LOADABLE_MODULE causes that, but it is necessary to get -module passed
to libtool.

I'll look into it later if you're not sure why, but that's the only thing
blocking committing it.

It doesn't seem that simple use of -O4 results in the plugin learning
what subtarget is desired. I presume that the llvm-gcc driver needs to
pass -mcpu down through collect2 into ld somehow. Has anybody solved
this already? Perhaps we should finally just put the feature string
into the bitcode?

That's not all. -disable-fp-elim will be dropped, for example. The libLTO
generated code assumes -mcpu=native, -march=native, frame pointers
eliminated, etc. This should all be flag controlled but nobody's bothered to
do it yet.

How does this work in the Darwin linker? Or doesn't it?

deep