I got the following error while compiling llvm and clang under cygwin. /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): undefined reference to `__register_frame' /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__register_frame' /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld: /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o): bad reloc address 0x0 in section `.pdata' collect2: error: ld returned 1 exit status /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Makefile.rules:1530: recipe for target `/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/bin/lli.exe' failed make[2]: *** [/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/bin/lli.exe] Error 1 make[2]: Leaving directory `/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/tools/lli' /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Makefile.rules:925: recipe for target `lli/.makeall' failed make[1]: *** [lli/.makeall] Error 2 make[1]: Leaving directory `/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/tools' /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Makefile.rules:876: recipe for target `all' failed make: *** [all] Error 1 I have no idea what that means. -- Thanks, Brian Herman college.nfshost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/91a17337/attachment.html>
Hi, We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the "indvars" pass only takes 45 seconds. It seems that the majority of the time is spent in comparing the complexity of the expression operands to sort them. I realize that the expression grows to be really large towards the end of the loop. I don't know of all the uses of the built SCEV. But I image it won't be very useful for such complex expressions. Yet, it's making the compile time much longer. So I'm wondering if it would make sense to abort the creation of SCEV when the expression gets really complex and large. Or is there any way to further optimize the performance of SCEV building for such cases. Thanks in advance for any response. Xiaoyi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/bba3dc48/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: MAD_test.ll Type: application/octet-stream Size: 11406 bytes Desc: MAD_test.ll URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/bba3dc48/attachment.obj>
On Mon, Jul 29, 2013 at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote:> Hi,**** > > ** ** > > We have a benchmark where there are 128 MAD computations in a loop. (See > the attached IR.) Creating SCEVs for these expressions takes a long time, > making the compile time too long. E.g., running opt with the “indvars” pass > only takes 45 seconds.**** > > ** ** > > It seems that the majority of the time is spent in comparing the > complexity of the expression operands to sort them. >Why not just fix this then? I assume the issue is that they all end up with the same length/complexity, so it both falls into the N^2 loop in GroupByComplexity, and the sort itself takes a long time because it compares operand by operand. This seems easy to fix by having GroupByComplexity calculate a very cheap hash prior to sorting when number of operands is large, and then using that hash before recursively comparing element by element to distinguish the cases. (You could also create/update this hash as you go, but that seems like it would be more work) Unless of course, they really are all the same expression, in which case, this is harder :)> **** > > ** ** > > I realize that the expression grows to be really large towards the end of > the loop.**** > > ** ** > > I don’t know of all the uses of the built SCEV. But I image it won’t be > very useful for such complex expressions. Yet, it’s making the compile time > much longer.**** > > ** ** > > So I’m wondering if it would make sense to abort the creation of SCEV when > the expression gets really complex and large. Or is there any way to > further optimize the performance of SCEV building for such cases.**** > > ** ** > > Thanks in advance for any response.**** > > ** ** > > Xiaoyi**** > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130729/e8d4fd9c/attachment.html>
Hi Brian, On 29/07/13 23:42, Brian Herman wrote:> I got the following error while compiling llvm and clang under cygwin. > > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): > undefined reference to `__register_frame'I register_frame is used to enable the debugger (gdb) to debug JIT'd code. It is a function provided by libgcc, to be more precise in libgcc_eh. Is it in your copy? $ nm libgcc_eh.a | grep register_fram 0000000000001960 T __deregister_frame 0000000000001950 T __deregister_frame_info 0000000000001830 T __deregister_frame_info_bases 0000000000001750 T __register_frame 0000000000001740 T __register_frame_info 00000000000016b0 T __register_frame_info_bases 0000000000001800 T __register_frame_info_table 0000000000001780 T __register_frame_info_table_bases 0000000000001810 T __register_frame_table Ciao, Duncan.> /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol > `__register_frame' > /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld: > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o): > bad reloc address 0x0 in section `.pdata' > collect2: error: ld returned 1 exit status > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Makefile.rules:1530: > recipe for target > `/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/bin/lli.exe' > failed > make[2]: *** > [/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/bin/lli.exe] > Error 1 > make[2]: Leaving directory > `/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/tools/lli' > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Makefile.rules:925: > recipe for target `lli/.makeall' failed > make[1]: *** [lli/.makeall] Error 2 > make[1]: Leaving directory > `/cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/tools' > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Makefile.rules:876: > recipe for target `all' failed > make: *** [all] Error 1 > I have no idea what that means. > > -- > > > Thanks, > Brian Herman > college.nfshost.com <http://college.nfshost.com> > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
I get this when I type: brianherman at windows-8-[REDACTED] ~ $ nm libgcc_eh.a | grep register_frame nm: 'libgcc_eh.a': No such file brianherman at windows-8-[REDACTED] ~ $ nm libgcc_eh.a | grep register_fram nm: 'libgcc_eh.a': No such file brianherman at windows-8-[REDACTED] ~ $ On Tue, Jul 30, 2013 at 7:51 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi Brian, > > > On 29/07/13 23:42, Brian Herman wrote: > >> I got the following error while compiling llvm and clang under cygwin. >> >> /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Release+Asserts/lib/**libLLVMMCJIT.a(**SectionMemoryManager.o):** >> SectionMemoryManager.cpp:(.**text+0x3b): >> undefined reference to `__register_frame' >> > > I register_frame is used to enable the debugger (gdb) to debug JIT'd code. > It > is a function provided by libgcc, to be more precise in libgcc_eh. Is it > in > your copy? > > $ nm libgcc_eh.a | grep register_fram > 0000000000001960 T __deregister_frame > 0000000000001950 T __deregister_frame_info > 0000000000001830 T __deregister_frame_info_bases > 0000000000001750 T __register_frame > 0000000000001740 T __register_frame_info > 00000000000016b0 T __register_frame_info_bases > 0000000000001800 T __register_frame_info_table > 0000000000001780 T __register_frame_info_table_**bases > 0000000000001810 T __register_frame_table > > Ciao, Duncan. > > /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Release+Asserts/lib/**libLLVMMCJIT.a(**SectionMemoryManager.o):** >> SectionMemoryManager.cpp:(.**text+0x3b): >> relocation truncated to fit: R_X86_64_PC32 against undefined symbol >> `__register_frame' >> /usr/lib/gcc/x86_64-pc-cygwin/**4.8.1/../../../../x86_64-pc-** >> cygwin/bin/ld: >> /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Release+Asserts/lib/**libLLVMMCJIT.a(**SectionMemoryManager.o): >> bad reloc address 0x0 in section `.pdata' >> collect2: error: ld returned 1 exit status >> /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Makefile.rules:1530: >> recipe for target >> `/cygdrive/c/Users/**brianherman/Desktop/llvm/llvm-** >> 3.3.src/Release+Asserts/bin/**lli.exe' >> failed >> make[2]: *** >> [/cygdrive/c/Users/**brianherman/Desktop/llvm/llvm-** >> 3.3.src/Release+Asserts/bin/**lli.exe] >> Error 1 >> make[2]: Leaving directory >> `/cygdrive/c/Users/**brianherman/Desktop/llvm/llvm-**3.3.src/tools/lli' >> /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Makefile.rules:925: >> recipe for target `lli/.makeall' failed >> make[1]: *** [lli/.makeall] Error 2 >> make[1]: Leaving directory >> `/cygdrive/c/Users/**brianherman/Desktop/llvm/llvm-**3.3.src/tools' >> /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Makefile.rules:876: >> recipe for target `all' failed >> make: *** [all] Error 1 >> I have no idea what that means. >> >> -- >> >> >> Thanks, >> Brian Herman >> college.nfshost.com <http://college.nfshost.com> >> >> >> >> >> >> >> ______________________________**_________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> >> > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >-- Thanks, Brian Herman college.nfshost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/fe3fc10a/attachment.html>
On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote:> Hi, > > We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the “indvars” pass only takes 45 seconds. > > It seems that the majority of the time is spent in comparing the complexity of the expression operands to sort them. > > I realize that the expression grows to be really large towards the end of the loop. > > I don’t know of all the uses of the built SCEV. But I image it won’t be very useful for such complex expressions. Yet, it’s making the compile time much longer. > > So I’m wondering if it would make sense to abort the creation of SCEV when the expression gets really complex and large. Or is there any way to further optimize the performance of SCEV building for such cases. > > Thanks in advance for any response.Nice test case. I tried printing the SCEV… oops. I haven’t seen a case this bad, but I know you’re not the first to run into this problem. There are two steps in GroupByComplexity, sorting (std::sort) and grouping (N^2). The sort calls SCEVComplexityCompare::compare() which can make multiple recursive calls for nodes with multiple operands. This looks like it could be a disaster for expressions that are not strictly trees--exponential in the size of the DAG. If you just have a very large tree with many similar looking subexpressions, then I’m not sure what to do except cut it into reasonable subtrees. AFAICT, it’s not just sorting that’s a problem but also grouping? Also, I think the shear depth of the createSCEV recursion is itself a problem. I don’t see any reason not to limit the size of SCEV expressions, but I also don’t have a brilliant idea for how to do it at the moment (other than the obvious depth cutoff). -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/8c20dfb6/attachment.html>