sebastianpoeplau
commented
4 years ago Hi @ttheodor,
There's no error on your side, and I can reproduce the problem. The TL;DR is that OpenJPEG seems to automatically use SSE instructions when they're available, resulting in code that SymCC doesn't understand. Building SymCC in release mode and using it to compile OpenJPEG avoids the error, but only by chance.
The longer version:
The assertion error Unhandled type for constant expression means that SymCC encounters a constant in the code that it doesn't understand. The function in question, opj_v4dwt_decode, contains conditionally compiled SSE code (https://github.com/uclouvain/openjpeg/blob/cbee7891a0ee664dd83ca09553d2e30da716a883/src/lib/openjp2/dwt.c#L2460). This is the cause of the error; to confirm, I ran the failing compiler command with regular clang, asking it to produce LLVM IR output:
$ clang -Dopenjp2_EXPORTS -Isrc/lib/openjp2 -O3 -DNDEBUG -fPIC -MD -MT src/lib/openjp2/CMakeFiles/openjp2.dir/dwt.c.o -MF src/lib/openjp2/CMakeFiles/openjp2.dir/dwt.c.o.d -S -emit-llvm -o- ../src/lib/openjp2/dwt.cThe output will be the LLVM representation of the C code; the function opj_v4dwt_decode indeed contains vector instructions:
define internal fastcc void @opj_v4dwt_decode(%struct.v4dwt_local* noalias nocapture readonly %0) unnamed_addr #8 {
...
%35 = phi <4 x float>* [ %47, %33 ], [ %30, %21 ]
%36 = load <4 x float>, <4 x float>* %35, align 16, !tbaa !127
%37 = fmul <4 x float> %36, <float 0x3FF3AECB00000000, float 0x3FF3AECB00000000, float 0x3FF3AECB00000000, float 0x3FF3AECB00000000>
...SymCC should fail when encountering those because we haven't implemented symbolic handling for them. (It's straight-forward and would be nice to have, but so far I haven't had the time.) What I didn't realize is that llvm_unreachable, the function that throws the error, doesn't abort in release builds. So a release version of SymCC would happily accept vector constants, returning some undefined value as the corresponding expression. However, executing the resulting OpenJPEG programs works just fine! The reason is, I think, that the operations performed on those particular vectors are floating-point arithmetic, which the QSYM backend always concretizes. Therefore, the nonsensical expression doesn't cause any harm...
Now, how should we fix this?
- As a quick-and-dirty solution, you can build OpenJPEG with a release version of SymCC.
- In projects where the user can disable SSE instructions via a build switch, doing so will avoid the error.
- I should return
nullptrfromSymbolizer::createValueExpression, so that at least the return value isn't undefined in release builds. It will still crash the program if the expression gets used though. - A proper solution would be to implement symbolic handling of vector instructions. This is definitely on the TODO list.
thetheodor
xupeng1231
Hi, I'm trying to build OpenJPEG but symcc (clang 10.0.1) is crushing. I've built the master branch of symcc and
1f1e9682of OpenJPEG with:CC=~/symcc/build/symcc CXX=~/symcc/build/sym++ SYMCC_NO_SYMBOLIC_INPUT=1 SYMCC_LIBCXX_PATH=/usr/include/c++/v1 cmake .. -DCMAKE_BUILD_TYPE=Release -DBUILD_THIRDPARTY=ONHowever, building
src/lib/openjp2/CMakeFiles/openjp2.dir/dwt.c.ofails with:Am I doing something wrong?
Thanks