[llvm-dev] Strange opt error in Value ("replaceAllUses of value with new value of different type!" assertion failure)
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 1 08:38:09 PST 2017
> On Feb 1, 2017, at 3:55 AM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hello.
> I'm getting the following error after adding some extra instrumentation in a module (LoopVectorize.cpp ) due to a bug in Value::replaceAllUsesWith (see more comments of mine below):
> Value::replaceAllUsesWith(New = i16* inttoptr (i16 51 to i16*)), this = %VectorGep = getelementptr i16, i16* inttoptr (i16 51 to i16*), <128 x i64> zeroinitializer, !dbg !17 ; this output is generated by me to see why error happens
> clang-3.9: /llvm/lib/IR/Value.cpp:380: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed.
> #0 0x00007fd937958700 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /llvm/lib/Support/Unix/Signals.inc:402:0
> #1 0x00007fd937958a9a PrintStackTraceSignalHandler(void*) /llvm/lib/Support/Unix/Signals.inc:470:0
> #2 0x00007fd937956b55 llvm::sys::RunSignalHandlers() /llvm/lib/Support/Signals.cpp:44:0
> #3 0x00007fd937957f4b SignalHandler(int) /llvm/lib/Support/Unix/Signals.inc:256:0
> #4 0x00007fd9365ff4b0 (/lib/x86_64-linux-gnu/libc.so.6+0x354b0)
> #5 0x00007fd9365ff428 gsignal /build/glibc-t3gR2i/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
> #6 0x00007fd93660102a abort /build/glibc-t3gR2i/glibc-2.23/stdlib/abort.c:91:0
> #7 0x00007fd9365f7bd7 __assert_fail_base /build/glibc-t3gR2i/glibc-2.23/assert/assert.c:92:0
> #8 0x00007fd9365f7c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
> #9 0x00007fd9397d3b4b llvm::Value::replaceAllUsesWith(llvm::Value*) /llvm/lib/IR/Value.cpp:383:0
> #10 0x00007fd9372f7ba1 llvm::UnrollLoop(llvm::Loop*, unsigned int, unsigned int, bool, bool, bool, unsigned int, llvm::LoopInfo*, llvm::ScalarEvolution*, llvm::DominatorTree*, llvm::AssumptionCache*, bool) /llvm/lib/Transforms/Utils
> #11 0x00007fd937ec812d tryToUnrollLoop(llvm::Loop*, llvm::DominatorTree&, llvm::LoopInfo*, llvm::ScalarEvolution*, llvm::TargetTransformInfo const&, llvm::AssumptionCache&, bool, llvm::Optional<unsigned int>, llvm::Optional<unsigned int>, llvm::Optional<bool>, l
> #12 0x00007fd937ec8415 (anonymous namespace)::LoopUnroll::runOnLoop(llvm::Loop*, llvm::LPPassManager&) /llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp:1019:0
> #13 0x00007fd93a11c695 llvm::LPPassManager::runOnFunction(llvm::Function&) /llvm/lib/Analysis/LoopPass.cpp:200:0
> #14 0x00007fd939759035 llvm::FPPassManager::runOnFunction(llvm::Function&) /llvm/lib/IR/LegacyPassManager.cpp:1526:0
> #15 0x00007fd9397591ec llvm::FPPassManager::runOnModule(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1547:0
> #16 0x00007fd9397595a9 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1603:0
> #17 0x00007fd939759d13 llvm::legacy::PassManagerImpl::run(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1706:0
> #18 0x00007fd939759f53 llvm::legacy::PassManager::run(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1738:0
> #19 0x00007fd93bda031a (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, llvm::raw_pwrite_stream*) /llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:762:0
> #20 0x00007fd93bda0482 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) /home/asusu/L
> #21 0x00007fd93c08253e clang::CodeGenAction::ExecuteAction() /llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:846:0
> #22 0x00007fd93b43c2f0 clang::FrontendAction::Execute() /llvm/tools/clang/lib/Frontend/FrontendAction.cpp:461:0
> #23 0x00007fd93b3d83cb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:877:0
> #24 0x00007fd93af41f67 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:241:0
> #25 0x0000000000448800 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /llvm/tools/clang/tools/driver/cc1_main.cpp:116:0
> #26 0x000000000043e5ce ExecuteCC1Tool(llvm::ArrayRef<char const*>, llvm::StringRef) /llvm/tools/clang/tools/driver/driver.cpp:301:0
> #27 0x000000000043f0e4 main /llvm/tools/clang/tools/driver/driver.cpp:382:0
> #28 0x00007fd9365ea830 __libc_start_main /build/glibc-t3gR2i/glibc-2.23/csu/../csu/libc-start.c:325:0
> #29 0x000000000043be39 _start (/llvm/build40/bin/clang-3.9+0x43be39)
>
> The part of the instrumented code causing this problem, as you might see also a bit from the error message above, is:
> %0 = sext <128 x i16> zeroinitializer to <128 x i64>, !dbg !17
> %VectorGep = getelementptr i16, i16* inttoptr (i16 51 to i16*), <128 x i64> %0, !dbg !17
> %1 = call <128 x i16> @llvm.masked.gather.v128i16(<128 x i16*> %VectorGep, i32 0, <128 x i1> <i1 true,
The type of %VectorGep seems to be <128 x i16*>, but you’re trying to replace it with `i16* inttoptr (i16 51 to i16*)` which is `i16 *`, and LLVM complains about the type mismatch. That seems expected?
—
Mehdi
>
> It seems it is exactly the zeroinitializer causing the problem because if I use a different constant value than zeroinitializer it no longer gives this error. I guess LLVM gets confused by the many different types zeroinitializer can have. Note that I'm using the LLVM source code from SVN repository from Jul 2016 - revision r274513, to which as you can see I did some changes to support wider vector types such as 128 x i16.
>
> Did anybody encounter such a problem before?
>
> Thank you,
> Alex
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
More information about the llvm-dev
mailing list