What are the optimizations that gold uses during the final link stage?

Project Infrastructure LLVM Dev List Archives
1

Hi,

I am using gold plugin with the option "-use-gold-plugin -Wl,-plugin-opt=also-emit-llvm" to compile apache.

I objdumped the final executable httpd to httpd.S.

I also compiled those per file bytecode into native code using the following:
llc filename.o
llvm-gcc -c filename.o.s -o filename.o.o

Then I objdumped filename.o.o to filename.o.S and compared some functions between httpd.S. and filename.o.S, and I found the order of some instructions are different.

Is this the expected behavior, probably because of some optimization during the final link stage? If this is the case, can you point me what those optimizations are, so that I could also apply them while compiling per file bytecode to native code.

Or am I using the wrong way to compile per file bytecode to native code?

Thanks,
Guoliang

2

Hi,

I am using gold plugin with the option "-use-gold-plugin
-Wl,-plugin-opt=also-emit-llvm" to compile apache.

I objdumped the final executable httpd to httpd.S.

I also compiled those per file bytecode into native code using the
following:
llc filename.o
llvm-gcc -c filename.o.s -o filename.o.o

Then I objdumped filename.o.o to filename.o.S and compared some
functions between httpd.S. and filename.o.S, and I found the order of
some instructions are different.

Is this the expected behavior, probably because of some optimization
during the final link stage? If this is the case, can you point me what
those optimizations are, so that I could also apply them while compiling
per file bytecode to native code.

Or am I using the wrong way to compile per file bytecode to native code?

Gold uses the libLTO interface. I think there is a small bug (strange
design?) in libLTO: lto_codegen_write_merged_modules will write the
bitcode files after they are merged and internalized, but before other
optimizations are run. We should probably change that or add a new
function to libLTO that gives us access to the optimized code.

Can someone more familiar with libLTO comment why write_merged_modules
writes the IL before it is optimized?

Thanks,
Guoliang

Cheers,

3

I am not sure why "before it is optimized?". May be this is gold specific ?

One of the use of this utility is a debugging aid. The linker can select to do this when -save-temps is used on the command line.

4

I am not sure why "before it is optimized?". May be this is gold specific ?

One of the use of this utility is a debugging aid. The linker can select to do this when -save-temps is used on the command line.

I think an example will explain. Lets say we have a function foo that
is unused. The output of lto_codegen_write_merged_modules will have
foo in it, but it will be marked as an internal function. The .o
produced by libLTO will not have foo anymore.

-
Devang

Cheers,

5

Would not it be useful to debug LLVM optimizer bugs ?

BTW, if you call lto_codegen_write_merged_modules() from linker after optimization but before generating machine code and you’ll get a .bc file without function foo.

In other words, when to use this hook is up to libLTO user. It is not required to use this hook all the time.

6

Would not it be useful to debug LLVM optimizer bugs ?

Yes. That is a good point for keeping it.

BTW, if you call lto_codegen_write_merged_modules() from linker after
optimization but before generating machine code and you'll get a .bc file
without function foo.
In other words, when to use this hook is up to libLTO user. It is not
required to use this hook all the time.

I see. Unfortunately there is no optimization function in lto.h. As
far as I can tell the optimizations are being done in
lto_codegen_compile which also generates machine code. Should I expose
a lto_codegen_optimize function and have lto_codegen_compile call it
if was not called by the user already?

-
Devang

Thanks,