[llvm-dev] Strange opt error in Value ("replaceAllUses of value with new value of different type!" assertion failure)

[Alex Susu via llvm-dev]

   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,

     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