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

Wed Feb 1 08:41:51 PST 2017

> On Feb 1, 2017, at 8:38 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
>> 
>> 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?

I just realized that you didn’t write the RAUW (correct?) and that it seems like a bug in UnrollLoop :)

That said the fact that the GEP is taking an i16 * and returns a pointer to a vector type by using a zero in the first index seems strange to me, is it valid? Does this pass the verifier?

— 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170201/3a252823/attachment.html>