llvm dev - Aug 2010 - [LLVMdev] What are the optimizations that gold uses during the final link stage?

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

On 19 August 2010 01:25, Guoliang Jin <jingl1345 at gmail.com>
wrote:
>  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,
-- 
Rafael Ávila de Espíndola

On Aug 31, 2010, at 9:54 AM, Rafael Espindola wrote:
> On 19 August 2010 01:25, Guoliang Jin <jingl1345 at gmail.com> wrote:
>>  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?
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.

-
Devang