[cfe-dev] Clang 'locks up' when compiling optimized
mats petersson via cfe-dev
cfe-dev at lists.llvm.org
Tue Jun 27 07:00:19 PDT 2017
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
On 27 June 2017 at 14:45, David Barto via cfe-dev <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
>
> Sometimes, my best code does nothing. Most of the rest of it has bugs.
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170627/c4fe108f/attachment.html>
More information about the cfe-dev
mailing list