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

If this information is useful, please help other people find it:
Share via:

Alex Susu via llvm-dev

2017-Feb-01 11:55 UTC

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

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

Mehdi Amini via llvm-dev

2017-Feb-01 16:38 UTC

head link

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

> 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

Mehdi Amini via llvm-dev

2017-Feb-01 16:41 UTC

head link

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

> 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>

Possibly Parallel Threads

Search for more seemingly similar threads

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

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

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

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

Possibly Parallel Threads