Open Meinersbur opened 7 years ago
Meinersbur
commented
7 years ago When this occurred in other places, we inserted a pointer-bitcast to match the stored value's type.
The type a pointer points to does not carry a lot of meaning, LLVM tends to just cast everything to i8*. LLVM might even move to have just a single pointer type (per address space).
The undef has probably just been introduced by bugpoint. The original problem might not have used an undef.
llvmbot
commented
7 years ago Debugging:
/ In BlockGenerators.cpp, line 695 / Builder.CreateStore(Val, Address); /****/
(lldb) po Val->getType()->getTypeID() PointerTyID
(lldb) Address->getType()->getTypeID() PointerTyID
But Val is pointer to type (i8* undef)
I think one way to solve this is to introduce a TypeID for Undef. As of now, the TypeIDs available are: http://llvm.org/doxygen/classllvm_1_1Type.html#a5e9e1c0dd93557be1b4ad72860f3cbda
^Although I think this would be a big design decision.
Anyway, I wanted to add an
assert(Val->getType()->getTypeID() == Address->getType()->getTypeID())
But I figured this is not true in a lot of cases.
Ideas?
Extended Description
The attached program crashes with:
$ opt -polly-process-unprofitable -polly-remarks-minimal -polly-use-llvm-names -polly-import-jscop-dir=C:\Users\Meinersbur\src\llvm\tools\polly\test -polly-codegen -S < bitmap_0.ll
Assertion failed: getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!", file C:\Users\Meinersbur\src\llvm\lib\IR\Instructions.cpp, line 1400