<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 1, 2017, at 8:38 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="">mehdi.amini@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Feb 1, 2017, at 3:55 AM, Alex Susu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">Hello.<br class=""> 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):<br class=""> 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<br class=""> 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.<br class=""> #0 0x00007fd937958700 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /llvm/lib/Support/Unix/Signals.inc:402:0<br class=""> #1 0x00007fd937958a9a PrintStackTraceSignalHandler(void*) /llvm/lib/Support/Unix/Signals.inc:470:0<br class=""> #2 0x00007fd937956b55 llvm::sys::RunSignalHandlers() /llvm/lib/Support/Signals.cpp:44:0<br class=""> #3 0x00007fd937957f4b SignalHandler(int) /llvm/lib/Support/Unix/Signals.inc:256:0<br class=""> #4 0x00007fd9365ff4b0 (/lib/x86_64-linux-gnu/libc.so.6+0x354b0)<br class=""> #5 0x00007fd9365ff428 gsignal /build/glibc-t3gR2i/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0<br class=""> #6 0x00007fd93660102a abort /build/glibc-t3gR2i/glibc-2.23/stdlib/abort.c:91:0<br class=""> #7 0x00007fd9365f7bd7 __assert_fail_base /build/glibc-t3gR2i/glibc-2.23/assert/assert.c:92:0<br class=""> #8 0x00007fd9365f7c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)<br class=""> #9 0x00007fd9397d3b4b llvm::Value::replaceAllUsesWith(llvm::Value*) /llvm/lib/IR/Value.cpp:383:0<br class=""> #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<br class=""> #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<br class=""> #12 0x00007fd937ec8415 (anonymous namespace)::LoopUnroll::runOnLoop(llvm::Loop*, llvm::LPPassManager&) /llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp:1019:0<br class=""> #13 0x00007fd93a11c695 llvm::LPPassManager::runOnFunction(llvm::Function&) /llvm/lib/Analysis/LoopPass.cpp:200:0<br class=""> #14 0x00007fd939759035 llvm::FPPassManager::runOnFunction(llvm::Function&) /llvm/lib/IR/LegacyPassManager.cpp:1526:0<br class=""> #15 0x00007fd9397591ec llvm::FPPassManager::runOnModule(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1547:0<br class=""> #16 0x00007fd9397595a9 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1603:0<br class=""> #17 0x00007fd939759d13 llvm::legacy::PassManagerImpl::run(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1706:0<br class=""> #18 0x00007fd939759f53 llvm::legacy::PassManager::run(llvm::Module&) /llvm/lib/IR/LegacyPassManager.cpp:1738:0<br class=""> #19 0x00007fd93bda031a (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, llvm::raw_pwrite_stream*) /llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:762:0<br class=""> #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<br class=""> #21 0x00007fd93c08253e clang::CodeGenAction::ExecuteAction() /llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:846:0<br class=""> #22 0x00007fd93b43c2f0 clang::FrontendAction::Execute() /llvm/tools/clang/lib/Frontend/FrontendAction.cpp:461:0<br class=""> #23 0x00007fd93b3d83cb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:877:0<br class=""> #24 0x00007fd93af41f67 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:241:0<br class=""> #25 0x0000000000448800 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /llvm/tools/clang/tools/driver/cc1_main.cpp:116:0<br class=""> #26 0x000000000043e5ce ExecuteCC1Tool(llvm::ArrayRef<char const*>, llvm::StringRef) /llvm/tools/clang/tools/driver/driver.cpp:301:0<br class=""> #27 0x000000000043f0e4 main /llvm/tools/clang/tools/driver/driver.cpp:382:0<br class=""> #28 0x00007fd9365ea830 __libc_start_main /build/glibc-t3gR2i/glibc-2.23/csu/../csu/libc-start.c:325:0<br class=""> #29 0x000000000043be39 _start (/llvm/build40/bin/clang-3.9+0x43be39)<br class=""><br class=""> The part of the instrumented code causing this problem, as you might see also a bit from the error message above, is:<br class=""> %0 = sext <128 x i16> zeroinitializer to <128 x i64>, !dbg !17<br class=""> %VectorGep = getelementptr i16, i16* inttoptr (i16 51 to i16*), <128 x i64> %0, !dbg !17<br class=""> %1 = call <128 x i16> @llvm.masked.gather.v128i16(<128 x i16*> %VectorGep, i32 0, <128 x i1> <i1 true,<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I just realized that you didn’t write the RAUW (correct?) and that it seems like a bug in UnrollLoop :)</div><div><br class=""></div><div>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?</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""></div><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class=""> 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.<br class=""><br class=""> Did anybody encounter such a problem before?<br class=""><br class="">Thank you,<br class=""> Alex<br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</blockquote></div></blockquote></div><br class=""></body></html>