Mehdi Amini via llvm-dev
2016-May-17 15:51 UTC
[llvm-dev] How to debug if LTO generate wrong code?
> 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>
Umesh Kalappa via llvm-dev
2016-May-17 18:21 UTC
[llvm-dev] [cfe-dev] How to debug if LTO generate wrong code?
Steven, As mehdi stated , the optimisation level is specific to linker and it enables Inter-Pro opts passes ,please refer function 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 >
Mehdi Amini via llvm-dev
2016-May-17 20:02 UTC
[llvm-dev] [cfe-dev] How to debug if LTO generate wrong code?
> 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 functionTo 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