Bug ID: 36433
           Summary: LoopVectorizer calls getCastInstrCost for an illegal
                    trunc instruction
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer

Created attachment 19895
reduced testcase


(gdb) p I->dump()
  %17 = trunc i32 %16 to i16

(gdb) p SrcVecTy->dump()
<2 x i32>

(gdb) p RetTy->dump()

(gdb) p VectorTy->dump()
<2 x i8>

canTruncateToMinimalBitwidth(I, VF) returns true

(gdb) p SrcVecTy->dump()
<2 x i8>

(gdb) p VectorTy->dump()
<2 x i16>

TargetTransformInfo::getCastInstrCost() :
(gdb) p Dst->dump()
<2 x i16>

(gdb) p Src->dump()
<2 x i8>

These types do not make sense for a truncate.


lib/Target/SystemZ/SystemZTargetTransformInfo.cpp:520: unsigned int
llvm::SystemZTTIImpl::getVectorTruncCost(llvm::Type*, llvm::Type*): Assertion
`SrcTy->getPrimitiveSizeInBits() > DstTy->getPrimitiveSizeInBits() && "Packing
must reduce size of vector type."' failed.

I would hope that the SystemZ assert is correct, and that the loop vectorizer
should not have made this call.


Please excuse my simple patch for disabling instruction combining, which is how
this test case appeared with csmith.

I first tried to reproduce this with opt -debug-pass=Arguments and then using
opt with all the explicit passes without -O3, but that did not work for some
reason. First I got

'LLVM ERROR: Trying to construct TargetPassConfig without a target machine.
Scheduling a CodeGen pass without a target triple set?'

This is weird, because I passed the triple, and it's also in the input file.

When I removed the -targetpassconfig argument, I didn't get the error.

Also did not know how to do something like -stop-before=loop-vectorize.

So, to rerun (with the patch for -disable-instcombine applied):

bin/opt -O3 -mcpu=z13 -o out.opt.ll tc_loopvec_trunc.ll
-enable-loop-versioning-licm -disable-instcombine -enable-tbaa=false

BTW, I see a *lot* of errors when I use my disable-instcombine option. Given
this, I feel like I must ask if instcombine is truly optional, or if other
passes depend on it? Before rewriting instcombine per some discussion I read a
while back ago, I hope people are aware of this...

You are receiving this mail because:
You are on the CC list for the bug.
llvm-bugs mailing list

Reply via email to