[llvm-dev] How to debug if LTO generate wrong code?
Shi, Steven via llvm-dev
llvm-dev at lists.llvm.org
Mon May 16 07:39:41 PDT 2016
Hi Umesh,
Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions.
I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in the LTO firstly, then enable them one by one later to narrow down my issue root cause. But when I try to disable the optimization by enforcing –O0 in the LTO build, I find the ld fails to recognize some clang bitcode library, and fail to link.
e.g. use the Clang_LTO_Fails_On_LD example in below bug attachment
https://sourceware.org/bugzilla/show_bug.cgi?id=20070
If I enforce the -O0 to disable the optimization in LTO, the ld fail to link:
~/clang38/bin/clang -o Hello.dll -flto -O0 -nostdlib -Wl,-n -Wl,-q -Wl,--gc-sections -Wl,-z,common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -Wl,-u,_ModuleEntryPoint -Wl,-Map,Hello.map -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,--start-group,, at static_library_files.lst -Wl,--end-group
BaseLib.lib: error adding symbols: File format not recognized
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
But if I enable the -O1, -O2, or higher -On, the ld link pass:
~/clang38/bin/clang -o Hello.dll -flto -O1 -nostdlib -Wl,-n -Wl,-q -Wl,--gc-sections -Wl,-z,common-page-size=0x40 -Wl,--entry,_ModuleEntryPoint -Wl,-u,_ModuleEntryPoint -Wl,-Map,Hello.map -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,--start-group,, at static_library_files.lst -Wl,--end-group
How can I correctly disable all the optimization in clang LTO? How can I know, enable and disable the specific optimizations in clang LTO? Any suggestion is welcomed!
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
> -----Original Message-----
> From: Umesh Kalappa [mailto:umesh.kalappa0 at gmail.com]
> Sent: Saturday, May 14, 2016 2:14 AM
> To: Shi, Steven <steven.shi at intel.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev at lists.llvm.org
> Subject: Re: [llvm-dev] How to debug if LTO generate wrong code?
>
> Steven,
>
> Brute force method is ,get the disassemble of the hanged function and
> try to check the difference with and without LTO in the generated
> code.
>
> or try to attach gdb and check for the instruction ,that cause the exception .
>
> Thank you
> ~Umesh
>
> On Fri, May 13, 2016 at 7:48 PM, Shi, Steven via llvm-dev
> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
> > Hello,
> >
> > I'm enabling clang LTO to improve code size of Uefi standard
> > (http://www.uefi.org/) firmware (https://github.com/tianocore/edk2),
> which
> > is mostly C code. My project is in https://github.com/shijunjing/edk2
> branch
> > llvm : https://github.com/shijunjing/edk2/tree/llvm. I find my most
> firmware
> > modules work well after enable LTO, but some X64 modules will not run
> (e.g.
> > hang with CPU exception) , and these X64 modules work well if build with
> the
> > LTO disabled (-fno-lto).
> >
> > I don’t know how to efficiently debug these LTO wrong code and
> investigate
> > if there is compiler’s bug. I appreciate if anyone can give me some
> > suggestions about the clang LTO issue debug method, commands, or BKMs.
> >
> >
> >
> > Below are my clang LTO build tools and options, I use clang 3.8 release
> > with binutils 2.26 ld (I’ve pushed ld support LLVM gold plugin
> > https://sourceware.org/bugzilla/show_bug.cgi?id=20070). Any suggestion
> is
> > welcome!
> >
> >
> >
> >
> >
> >
> >
> > ##################
> >
> > # CLANGLTO38 X64 definitions
> >
> > ##################
> >
> > *_CLANGLTO38_X64_OBJCOPY_PATH =
> DEF(GCC53_X64_PREFIX)objcopy
> >
> > *_CLANGLTO38_X64_CC_PATH = DEF(CLANG38_X64_PREFIX)clang
> >
> > *_CLANGLTO38_X64_SLINK_PATH = DEF(CLANG38_X64_PREFIX)llvm-
> ar
> >
> > *_CLANGLTO38_X64_DLINK_PATH =
> DEF(CLANG38_X64_PREFIX)clang
> >
> > *_CLANGLTO38_X64_ASM_PATH = DEF(CLANG38_X64_PREFIX)clang
> >
> > *_CLANGLTO38_X64_PP_PATH = DEF(CLANG38_X64_PREFIX)clang
> >
> > *_CLANGLTO38_X64_RC_PATH = DEF(GCC53_X64_PREFIX)objcopy
> >
> >
> >
> > *_CLANGLTO38_X64_CC_FLAGS = -c -fshort-wchar -fno-strict-aliasing -
> Wall
> > -Werror -Wno-array-bounds -Wno-empty-body -ffunction-sections
> > -fdata-sections -include AutoGen.h -
> DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
> > -fno-stack-protector -fno-builtin -mms-bitfields -Wno-address
> > -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-
> pragmas
> > -Wno-tautological-constant-out-of-range-compare
> > -Wno-incompatible-library-redeclaration -target x86_64-pc-linux-gnu
> > -fno-asynchronous-unwind-tables -m64 -Wno-enum-conversion
> > "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=large -g -Os
> -flto
> >
> > *_CLANGLTO38_X64_DLINK_FLAGS = -flto -nostdlib -Wl,-n -Wl,-q
> > -Wl,--gc-sections -Wl,-z,common-page-size=0x40
> > -Wl,--entry,$(IMAGE_ENTRY_POINT) -Wl,-u,$(IMAGE_ENTRY_POINT)
> > -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map -Wl,-melf_x86_64
> > -Wl,--oformat=elf64-x86-64
> >
> > *_CLANGLTO38_X64_ASM_FLAGS = -c -x assembler -imacros
> > $(DEST_DIR_DEBUG)/AutoGen.h -m64 -target x86_64-pc-linux-gnu
> >
> > *_CLANGLTO38_X64_RC_FLAGS = -I binary -O elf64-x86-64 -B
> > i386 --rename-section .data=.hii
> >
> > *_CLANGLTO38_X64_NASM_FLAGS = -f elf64
> >
> >
> >
> >
> >
> >
> >
> > 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/540e803b/attachment.html>
More information about the llvm-dev
mailing list