[llvm-bugs] [Bug 41270] New: opt -instcombine crashes with Assertion `V->getType()->isVectorTy() && "can't reorder non-vector elements"' failed.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41270

            Bug ID: 41270
           Summary: opt -instcombine crashes with Assertion
                    `V->getType()->isVectorTy() && "can't reorder
                    non-vector elements"' failed.
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 21691
  --> https://bugs.llvm.org/attachment.cgi?id=21691&action=edit
Reproducer

Reproduce with:
 opt -S -o - bbi-26476.ll -instcombine

which yields

opt: ../lib/Transforms/InstCombine/InstCombineVectorOps.cpp:1117: llvm::Value
*evaluateInDifferentElementOrder(llvm::Value *, ArrayRef<int>): Assertion
`V->getType()->isVectorTy() && "can't reorder non-vector elements"' failed.
Stack dump:
0.      Program arguments: build-all/bin/opt -instcombine bbi-26476.ll -S -o - 
1.      Running pass 'Function Pass Manager' on module 'bbi-26476.ll'.
2.      Running pass 'Combine redundant instructions' on function '@f1'
 #0 0x00000000022ddd44 PrintStackTraceSignalHandler(void*)
(build-all/bin/opt+0x22ddd44)
 #1 0x00000000022dbd30 llvm::sys::RunSignalHandlers()
(build-all/bin/opt+0x22dbd30)
 #2 0x00000000022de0a8 SignalHandler(int) (build-all/bin/opt+0x22de0a8)
 #3 0x00007f5ca602d330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
 #4 0x00007f5ca4c1cc37 gsignal
/build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
 #5 0x00007f5ca4c20028 abort
/build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0
 #6 0x00007f5ca4c15bf6 __assert_fail_base
/build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0
 #7 0x00007f5ca4c15ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
 #8 0x0000000001f11c94 evaluateInDifferentElementOrder(llvm::Value*,
llvm::ArrayRef<int>) (build-all/bin/opt+0x1f11c94)
 #9 0x0000000001f11535 evaluateInDifferentElementOrder(llvm::Value*,
llvm::ArrayRef<int>) (build-all/bin/opt+0x1f11535)
#10 0x0000000001f0fa5d
llvm::InstCombiner::visitShuffleVectorInst(llvm::ShuffleVectorInst&)
(build-all/bin/opt+0x1f0fa5d)
#11 0x0000000001e528ba llvm::InstCombiner::run() (build-all/bin/opt+0x1e528ba)
#12 0x0000000001e54a11 combineInstructionsOverFunction(llvm::Function&,
llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&,
llvm::TargetLibraryInfo&, llvm::DominatorTree&,
llvm::OptimizationRemarkEmitter&, bool, llvm::LoopInfo*)
(build-all/bin/opt+0x1e54a11)
#13 0x0000000001e550eb
llvm::InstructionCombiningPass::runOnFunction(llvm::Function&)
(build-all/bin/opt+0x1e550eb)
#14 0x0000000001ceb35d llvm::FPPassManager::runOnFunction(llvm::Function&)
(build-all/bin/opt+0x1ceb35d)
#15 0x0000000001ceb618 llvm::FPPassManager::runOnModule(llvm::Module&)
(build-all/bin/opt+0x1ceb618)
#16 0x0000000001ceba7a llvm::legacy::PassManagerImpl::run(llvm::Module&)
(build-all/bin/opt+0x1ceba7a)
#17 0x00000000007c49af main (build-all/bin/opt+0x7c49af)
#18 0x00007f5ca4c07f45 __libc_start_main
/build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0
#19 0x00000000007a99d9 _start (build-all/bin/opt+0x7a99d9)
Abort


When it fails, V is

(gdb) p V->dump()
i64 0

and if I go up one frame and look at I we get

#5  0x0000000003480aa1 in evaluateInDifferentElementOrder (V=0x7078dc8,
Mask=llvm::ArrayRef of length 4 = {...}) at
../lib/Transforms/InstCombine/InstCombineVectorOps.cpp:1174
1174            Value *V = evaluateInDifferentElementOrder(I->getOperand(i),
Mask);
(gdb) p I->dump()
  %tmp2 = getelementptr inbounds [4 x i16], <4 x [4 x i16]*> %.splat, i64 0,
i64 3

So I suppose the problem is that evaluateInDifferentElementOrder doesn't
correctly handle the case that a vector gep can have scalar arguments.

This starts crashing quite recently with r352440, but the failing assert is
old, introduced in r182976 in 2013.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190328/bfb7bdf2/attachment.html>