[llvm-dev] How to debug if LTO generate wrong code?

[Mehdi Amini via llvm-dev]

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello,
> Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2. By nm listing the foo1~4 symbols , I can see these different optimizations really works. 
> 1.       How can I know what different optimizations are used by the clang LTO among -O0, -O1 and -O2?

LTO is linker specific, clang is only forwarding the option to the linker here.

> 2.       Is the compiler domain optimization (e.g. clang/llvm) or the linker (e.g. ld) domain optimization make these difference?

In you case, you invoke clang with "emit-llvm", without any optimization level, so you get O0.
For what the linker is doing at these optimizations levels, again this is linker specific.

> 3.       How can I explicitly enable or disable these specific optimizations besides using -O0, -O1, -O2?

If you're talking about the LTO, this is linker specific again (ld is not the same program on every platform). For instance there is no such thing as O0/O1/O2 on OS X.


>  
>  
> $clang -emit-llvm -c main.c -o main.bc
> $clang -emit-llvm -c a.c -o a.bc
> $llvm-ar cr main.lib main.bc
> $llvm-ar cr a.lib a.bc
> $clang -O0 -flto main.lib a.lib -o main0
> $clang -O1 -flto main.lib a.lib -o main1
> $clang -O2 -flto main.lib a.lib -o main2
>  
> $nm main0
> …
> 00000000004005a0 t foo1
> 0000000000400580 t foo2
> 00000000004005e0 t foo3
> 0000000000400530 t foo4
> 0000000000400500 t frame_dummy
> …
> $ nm main1
> …
> 0000000000400550 t foo1
> 0000000000400580 t foo3
> 0000000000400530 t foo4
> 0000000000400500 t frame_dummy
> …
> $ nm main2
> …
> 00000000004004d0 t frame_dummy
> …
>  
> From blew verbose output, tt seems only linker( e.g. ld) is invovled to do the optimization?

Yes.
Usually the LTO pipeline is a bit different from what you're doing, I'm used to see:

$clang -flto -O3 -c main.c -o main.o
$clang -flto -O3 -c a.c -o a.o
$clang -flto -O3 main.o a.o -o main0


-- 
Mehdi



>  
> $ clang -O2 -flto main.lib a.lib -o main2 -v
> clang version 3.8.0 (tags/RELEASE_380/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/local/bin
> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.1
> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
> Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0
> Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0
> Candidate multilib: .;@m64
> Candidate multilib: 32;@m32
> Selected multilib: .;@m64
> "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o main2 /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0/crtbegin.o -L/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0 -L/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../lib64 -L/usr/local/bin/../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib -plugin /usr/local/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 -plugin-opt=O2 main.lib a.lib -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o
>  
>  
> Steven Shi
> Intel\SSG\STO\UEFI Firmware
>  
> Tel: +86 021-61166522
> iNet: 821-6522
>  
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160517/2cc421f2/attachment.html>