LLVM crashing while trying to build SPEC with Clang

Hello,

I am building the SPEC 2006 Benchmark with Clang as the compiler. I have written a function pass in LLVM and I am trying to run that for SPEC by invoking the pass in the build options of SPEC. The build options of SPEC are in a *.cfg config file, which allows us to specify the choice of compiler while building SPEC. (https://www.spec.org/cpu2006/Docs/install-guide-unix.html)

The pass runs for several functions, but llvm crashes at a certain point. I am checking dependencies between various loops in a function in that pass.

The crash message and stack dump is:

clang-9: /media/kiit/3E9AF7519AF703E5/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp:823: llvm::AliasResult llvm::BasicAAResult::alias(const llvm::MemoryLocation&, const llvm::MemoryLocation&, llvm::AAQueryInfo&): Assertion `notDifferentParent(LocA.Ptr, LocB.Ptr) && “BasicAliasAnalysis doesn’t support interprocedural queries.”’ failed.
Stack dump:
0. Program arguments: /media/kiit/3E9AF7519AF703E5/llvm/bin/clang-9 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name check_unitarity.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /media/kiit/3E9AF7519AF703E5/New_Spec/cpu2006/benchspec/CPU2006/433.milc/run/build_base_amd64-m64-gcc42-nn.0006/check_unitarity.gcno -resource-dir /media/kiit/3E9AF7519AF703E5/llvm/lib/clang/9.0.0 -D SPEC_CPU -D NDEBUG -I . -D FN -D FAST -D CONGRAD_TMP_VECTORS -D DSLASH_TMP_LINKS -D SPEC_CPU_LP64 -I/opt/intel/compilers_and_libraries_2019.2.187/linux/ipp/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/mkl/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/pstl/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/tbb/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/tbb/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/daal/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/ipp/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/mkl/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/pstl/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/tbb/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/tbb/include -I/opt/intel/compilers_and_libraries_2019.2.187/linux/daal/include -internal-isystem /usr/local/include -internal-isystem /media/kiit/3E9AF7519AF703E5/llvm/lib/clang/9.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /media/kiit/3E9AF7519AF703E5/New_Spec/cpu2006/benchspec/CPU2006/433.milc/run/build_base_amd64-m64-gcc42-nn.0006 -ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc -fdiagnostics-show-option -load /media/kiit/3E9AF7519AF703E5/llvm-pass-skeleton/build/skeleton/libSkeletonPass.so -o check_unitarity.o -x c check_unitarity.c -faddrsig

  1. parser at end of file
  2. Per-function optimization
  3. Running pass ‘Unnamed pass: implement Pass::getPassName()’ on function ‘@check_su3
    #0 0x0000000004f2a60f llvm::sys::PrintStackTrace(llvm::raw_ostream&) /media/kiit/3E9AF7519AF703E5/llvm-project/llvm/lib/Support/Unix/Signals.inc:494:0

I have included my function pass and the SPEC Config file(*.cfg) here.

Thanks,
Bodhisatwa

Skeleton.cpp (7.42 KB)

s1.cfg (10.6 KB)

It seems that your pass is somehow passing pointers defined in different functions to the alias interface, maybe you cache them in one run invocation and use them in the next?

The assertion text: BasicAliasAnalysis doesn't support interprocedural queries.
The assertion is in /media/kiit/3E9AF7519AF703E5/llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp line 823
The function is llvm::AliasResult llvm::BasicAAResult::alias(const llvm::MemoryLocation&, const llvm::MemoryLocation&, llvm::AAQueryInfo&)
To get a better idea where in your code the invocation is build it in debug mode.

Cheers,
  Johannes

The SSA value %4 is defined in each loop with different types. They cannot be in the same function.