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

[Mehdi Amini via cfe-dev]

> On May 17, 2016, at 11:21 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote:
> 
> Steven,
> 
> As mehdi stated , the optimisation level is specific to linker and it
> enables Inter-Pro  opts passes ,please  refer function

To be very clear: the -O option may trigger *linker* optimizations as well, independently of LTO.

-- 
Mehdi



> 
> PassManagerBuilder::addLTOOptimizationPasses()  at
> http://llvm.org/docs/doxygen/html/PassManagerBuilder_8cpp_source.html
> 
> internal options to disable to them ,i don't think ,you can do so.
> 
> Thank you
> ~Umesh
> 
> On Tue, May 17, 2016 at 9:21 PM, Mehdi Amini via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> 
>> 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, 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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev