[PATCH] D78847: [LV] Fix recording of BranchTakenCount for FoldTail

Anh Tuyen Tran via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 10 15:58:12 PDT 2020


anhtuyen added a comment.

Hello,

The new fix delivered in this patch has caused an assert failure with a testcase having a loop with a very small trip count going through fold tail by masking. 
The reduced testcase is as follows. The options are: **-loop-vectorize -force-vector-interleave=4**

For your reference, at the time of this writing, my HEAD is at commit 2d3f5a62de8e5d2cc25aaa49d0a00d31ed32544a <https://reviews.llvm.org/rG2d3f5a62de8e5d2cc25aaa49d0a00d31ed32544a>

  $ cat simple.ll
  define void @foo() {
  entry:
    br label %for.body
  
  for.cond.cleanup:
    ret void
  
  for.body:
    %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ]
    %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
    %exitcond = icmp eq i64 %indvars.iv.next, 15
    br i1 %exitcond, label %for.cond.cleanup, label %for.body
  }



  $ opt -loop-vectorize -force-vector-interleave=4 -S ./simple.ll
  
  opt: llvm-project/llvm/include/llvm/IR/Instructions.h:1140: void llvm::ICmpInst::AssertOK(): Assertion `getOperand(0)->getType() == getOperand(1)->getType() && "Both operands to ICmp instruction are not of the same type!"' failed.
  
  Stack dump:
  0.      Program arguments: build/bin/opt -loop-vectorize -force-vector-interleave=4 -S -debug-only=loop-vectorize simple.ll
  1.      Running pass 'Function Pass Manager' on module 'simple.ll'.
  2.      Running pass 'Loop Vectorization' on function '@foo'
   #0 0x00007c2509ec9bf4 PrintStackTraceSignalHandler(void*) (build/bin/../lib/libLLVMSupport.so.11git+0x1e9bf4)
   #1 0x00007c2509ec6b98 llvm::sys::RunSignalHandlers() (build/bin/../lib/libLLVMSupport.so.11git+0x1e6b98)
   #2 0x00007c2509ec9f04 SignalHandler(int) (build/bin/../lib/libLLVMSupport.so.11git+0x1e9f04)
   #3 0x00007c250ff004d8 (linux-vdso64.so.1+0x4d8)
   #4 0x00007c25090de98c __libc_signal_restore_set /build/glibc-uvws04/glibc-2.27/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:80:0
   #5 0x00007c25090de98c raise /build/glibc-uvws04/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:48:0
   #6 0x00007c25090e0be0 abort /build/glibc-uvws04/glibc-2.27/stdlib/abort.c:79:0
   #7 0x00007c25090cbb38 __assert_fail_base /build/glibc-uvws04/glibc-2.27/assert/assert.c:92:0
   #8 0x00007c25090cbbe4 __assert_fail /build/glibc-uvws04/glibc-2.27/assert/assert.c:101:0
   #9 0x00007c25098fe518 llvm::ICmpInst::AssertOK() (build/bin/../lib/libLLVMVectorize.so.11git+0x7e518)
  #10 0x00007c25098cc31c llvm::IRBuilderBase::CreateICmp(llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine const&) (build/bin/../lib/libLLVMVectorize.so.11git+0x4c31c)
  #11 0x00007c250996130c llvm::VPInstruction::generateInstruction(llvm::VPTransformState&, unsigned int) (build/bin/../lib/libLLVMVectorize.so.11git+0xe130c)
  #12 0x00007c2509961810 llvm::VPInstruction::execute(llvm::VPTransformState&) (build/bin/../lib/libLLVMVectorize.so.11git+0xe1810)
  #13 0x00007c25099604bc llvm::VPBasicBlock::execute(llvm::VPTransformState*) (build/bin/../lib/libLLVMVectorize.so.11git+0xe04bc)
  #14 0x00007c25099620a8 llvm::VPlan::execute(llvm::VPTransformState*) (build/bin/../lib/libLLVMVectorize.so.11git+0xe20a8)
  #15 0x00007c25098eb368 llvm::LoopVectorizationPlanner::executePlan(llvm::InnerLoopVectorizer&, llvm::DominatorTree*) (build/bin/../lib/libLLVMVectorize.so.11git+0x6b368)
  #16 0x00007c25098f7380 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (build/bin/../lib/libLLVMVectorize.so.11git+0x77380)
  #17 0x00007c25098f8b74 llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&, std::function<llvm::LoopAccessInfo const& (llvm::Loop&)>&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (build/bin/../lib/libLLVMVectorize.so.11git+0x78b74)
  #18 0x00007c2509903320 (anonymous namespace)::LoopVectorize::runOnFunction(llvm::Function&) (build/bin/../lib/libLLVMVectorize.so.11git+0x83320)
  #19 0x00007c250af0069c llvm::FPPassManager::runOnFunction(llvm::Function&) (build/bin/../lib/libLLVMCore.so.11git+0x27069c)
  #20 0x00007c250af00b00 llvm::FPPassManager::runOnModule(llvm::Module&) (build/bin/../lib/libLLVMCore.so.11git+0x270b00)
  #21 0x00007c250af012b4 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build/bin/../lib/libLLVMCore.so.11git+0x2712b4)
  #22 0x00007c250af0195c llvm::legacy::PassManager::run(llvm::Module&) (build/bin/../lib/libLLVMCore.so.11git+0x27195c)
  #23 0x0000000010031aec main (build/bin/opt+0x10031aec)
  #24 0x00007c25090b441c generic_start_main /build/glibc-uvws04/glibc-2.27/csu/../csu/libc-start.c:310:0
  #25 0x00007c25090b4618 __libc_start_main /build/glibc-uvws04/glibc-2.27/csu/../sysdeps/unix/sysv/linux/powerpc/libc-start.c:116:0

It looks like setting a vector as BackedgeTakenCount has caused the type mismatch when generating the icmp instructions

  ...
  vector.body:                                      ; preds = %vector.body, %vector.ph
    %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
    %induction = add i64 %index, 0
    %induction1 = add i64 %index, 1
    %induction2 = add i64 %index, 2
    %induction3 = add i64 %index, 3
    %0 = icmp ule i64 %induction, 14   <======== assert when generating this line

In this example, the operand[0] (%induction) correctly has type i64, but the loop bound (14) is of vector type <1 x i64>

There might be multiple ways to address this assert failure. I list below a few simple ones for your reference: they might or might not be a good solution at all.

1. Option 1: Not to generate the icmp instructions for %induction. In the particular case of this testcase, these instructions seem to be redundant.
2. Option 2: If we are to generate the icmp instructions above, can we set the BackedgeTakenCount to the State depending on the type of the first operand? In cases like this one when the first operand is not a vector type, using Value *TCMO instead of Value *VTCMO might be an option.

I will open a Bugzzila and copy its link to this page when my password reset goes through.

Thanks,
Anh


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78847/new/

https://reviews.llvm.org/D78847





More information about the llvm-commits mailing list