[cfe-dev] Clang 'locks up' when compiling optimized
David Barto via cfe-dev
cfe-dev at lists.llvm.org
Tue Jun 27 07:09:17 PDT 2017
> On Jun 27, 2017, at 7:00 AM, mats petersson <mats at planetcatfish.com> wrote:
>
> 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)
>
> 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(); }`
>
> --
> Mats
>
This was left running overnight. It was completely locked and wasn’t making any progress.
Just scraping the compile line from the PS output and pasting it into a shell has the compiler running in about 5-8 seconds. So something about running this through my compile daemon did something weird.
It doesn’t happen on the same file every time. If I delete the code cache and re-run my system again, it will pick another file to lock up on, or possibly run to completion without locking up. It appears random.
David
> On 27 June 2017 at 14:45, David Barto via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> The file isn’t very large, at 181949 bytes, and is a machine generated bit of code.
>
> 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.
>
> 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:
>
> struct rlimit rlim;
> rlim.rlim_cur = rlim.rlim_max = m_compile_max_seconds; // 30
>
> if (0 != setrlimit(RLIMIT_CPU, &rlim))
> {
> xthrow(Sys_rlimit, errno, "system", "can't bound compilation time");
> }
>
> rlim.rlim_cur = rlim.rlim_max = m_compile_max_memory * (1 << 20); // 500 MB
>
> if (0 != setrlimit(RLIMIT_AS, &rlim))
> {
> xthrow(Sys_rlimit, errno, "system", "can't limit compiler memory usage");
> }
>
> 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.
>
> 501 59880 46191 4004 0 31 10 2495004 9612 - SN 0 ?? 0:00.02 /opt/local/libexec/llvm-4.0/bin/clang++ -pipe -c -o /Users/barto/UnixEnvironment/CSI/internal/repo4/internal.0/code/381/1.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/UnixEnvironment/CSI/repo4/lib -I/Users/barto/UnixEnvironment/CSI/repo4/lib/cgrsrc /Users/barto/UnixEnvironment/CSI/internal/repo4/internal.0/code/381/1.cpp
> 501 59881 59880 4004 0 31 10 2554904 33884 - SN 0 ?? 21:37.14 /opt/local/libexec/llvm-4.0/bin/clang -cc1 -triple x86_64-apple-macosx10.10.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-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/CSI/internal/repo4/internal.0/code/381/1.gcno -resource-dir /opt/local/libexec/llvm-4.0/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/CSI/repo4/lib -I /Users/barto/UnixEnvironment/CSI/repo4/lib/cgrsrc -stdlib=libc++ -O3 -Winvalid-pch -std=gnu++14 -fdeprecated-macro -fdebug-compilation-dir /Users/barto/UnixEnvironment/CSI/repo4/bin -ferror-limit 19 -fmessage-length 0 -stack-protector 2 -fblocks -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /Users/barto/UnixEnvironment/CSI/internal/repo4/internal.0/code/381/1.opt -x c++ /Users/barto/UnixEnvironment/CSI/internal/repo4/internal.0/code/381/1.cpp
>
> David
>
>
> David Barto
> barto at cambridgesemantics.com <mailto:barto at cambridgesemantics.com>
>
> Sometimes, my best code does nothing. Most of the rest of it has bugs.
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
David Barto
barto at cambridgesemantics.com
Sometimes, my best code does nothing. Most of the rest of it has bugs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170627/5aa45958/attachment.html>
More information about the cfe-dev
mailing list