<div dir="ltr"><div>Does it actually lock up, or just take a very long time. LLVM does have problems with very large functions, which leads to long times for "instruction selection" (worse in debug builds of the compiler too)<br><br> The same applies to g++ - I had something that was about 100k lines that took over 15 minutes to compile a while back - tweaking the options changed it to about 20s. Just because one compiler is "good" and the other "bad" doesn't mean that the "bad" one is broken, it's all depending on what the code looks like, one may well run through the compilation quickly, and the other take very long - "The devil is in the detail". In my g++ case, it was "dead store elimination, that took a long time, and on a file that is several megabytes, the difference with DSE enabled was a few kilobytes - from what I can tell [without looking at the code], g++ does DSE in O(n^2) time, by something akin to `for_each(instructions) { for_each(instructions) check_this_instruction(); }`<br><br>--<br></div>Mats<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 June 2017 at 14:45, David Barto via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The file isn’t very large, at 181949 bytes, and is a machine generated bit of code.</div><div><br></div><div>The strange thing is that if I run the compile by hand by cutting/pasting the line into a shell window, it compiles in seconds. I run the same code generation/compile/execution with g++ (5.1) and it never locks up.</div><div><br></div><div>Another thing, the code is compiled from a daemon that places the compiler under execution limits. If it runs for more than 30 seconds or uses more than 500MB of RAM, it should have the appropriate limit applied to it. I fork the daemon and before exec() for the compiler do the following:</div><div><br></div><div><font face="PT Mono">      struct rlimit rlim;<br>      rlim.rlim_cur = rlim.rlim_max = m_compile_max_seconds;<span class="m_6451577194478360902Apple-tab-span" style="white-space:pre-wrap">    </span>// 30<br><br>      if (0 != setrlimit(RLIMIT_CPU, &rlim))<br>      {<br>        xthrow(Sys_rlimit, errno, "system", "can't bound compilation time");<br>      }<br><br>      rlim.rlim_cur = rlim.rlim_max = m_compile_max_memory * (1 << 20);<span class="m_6451577194478360902Apple-tab-span" style="white-space:pre-wrap">        </span>// 500 MB<br><br>      if (0 != setrlimit(RLIMIT_AS, &rlim))<br>      {<br>        xthrow(Sys_rlimit, errno, "system", "can't limit compiler memory usage");<br>      }<br></font><br></div><div>This is the compile that locked up. If anyone believes that looking at the source would make a difference, let me know and I’ll send it along.</div><div><br></div><div>  501 59880 46191     4004   0  31 10  2495004   9612 -      SN                  0 ??         0:00.02 /opt/local/libexec/llvm-4.0/<wbr>bin/clang++ -pipe -c -o /Users/barto/<wbr>UnixEnvironment/CSI/internal/<wbr>repo4/internal.0/code/381/1.<wbr>opt -O3 -Winvalid-pch -march=core2 -fstack-protector-strong -D_BSD_SOURCE -DFOR_SPARQL -D_REENTRANT -D_PTHREADS -DTHREAD -D_GLIBCXX_USE_DEPRECATED=0 -DTURBO_GENCODE=1 -DDO_CASSANDRA=0 -DMEM_LIMIT_LEAK_CHECKING -DFULL_RESERVATIONS -DGCC5 -D_DARWIN_C_SOURCE -DDARWIN -DMAC_OSX=1 -std=gnu++14 -m64 -fPIC -I/Users/barto/<wbr>UnixEnvironment/CSI/repo4/lib -I/Users/barto/<wbr>UnixEnvironment/CSI/repo4/lib/<wbr>cgrsrc /Users/barto/UnixEnvironment/<wbr>CSI/internal/repo4/internal.0/<wbr>code/381/1.cpp</div>  501 59881 59880     4004   0  31 10  2554904  33884 -      SN                  0 ??        <b>21:37.14</b> /opt/local/libexec/llvm-4.0/<wbr>bin/clang -cc1 -triple x86_64-apple-macosx10.10.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-<wbr>usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name 1.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 274.2 -dwarf-column-info -debugger-tuning=lldb -coverage-notes-file /Users/barto/UnixEnvironment/<wbr>CSI/internal/repo4/internal.0/<wbr>code/381/1.gcno -resource-dir /opt/local/libexec/llvm-4.0/<wbr>bin/../lib/clang/4.0.0 -D _BSD_SOURCE -D FOR_SPARQL -D _REENTRANT -D _PTHREADS -D THREAD -D _GLIBCXX_USE_DEPRECATED=0 -D TURBO_GENCODE=1 -D DO_CASSANDRA=0 -D MEM_LIMIT_LEAK_CHECKING -D FULL_RESERVATIONS -D GCC5 -D _DARWIN_C_SOURCE -D DARWIN -D MAC_OSX=1 -I /Users/barto/UnixEnvironment/<wbr>CSI/repo4/lib -I /Users/barto/<wbr>UnixEnvironment/CSI/repo4/lib/<wbr>cgrsrc -stdlib=libc++ -O3 -Winvalid-pch -std=gnu++14 -fdeprecated-macro -fdebug-compilation-dir /<wbr>Users/barto/UnixEnvironment/<wbr>CSI/repo4/bin -ferror-limit 19 -fmessage-length 0 -stack-protector 2 -fblocks -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-<wbr>signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /Users/barto/UnixEnvironment/<wbr>CSI/internal/repo4/internal.0/<wbr>code/381/1.opt -x c++ /Users/barto/UnixEnvironment/<wbr>CSI/internal/repo4/internal.0/<wbr>code/381/1.cpp<br><br><div><span class="m_6451577194478360902Apple-tab-span" style="white-space:pre-wrap">      </span>David</div><div><br></div><br><div>David Barto<br><a href="mailto:barto@cambridgesemantics.com" target="_blank">barto@cambridgesemantics.com</a><br><br>Sometimes, my best code does nothing. Most of the rest of it has bugs.<br><br><br></div><br></div><br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>