[llvm] [InstCombine] Fold (X / C) < X and (X >> C) < X into X > 0 (PR #85555)
via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 19 08:17:17 PDT 2024
goldsteinn wrote:
> Oops, looks like I forgot to run tests on my machine before pushing the changes. I've localised the source of one of many failing tests to this function in `getelementptr.ll`:
>
> ```
> define i1 @test10(ptr %x, ptr %y) {
> ; CHECK-LABEL: @test10(
> ; CHECK-NEXT: [[T4:%.*]] = icmp eq ptr [[X:%.*]], [[Y:%.*]]
> ; CHECK-NEXT: ret i1 [[T4]]
> ;
> %t1 = getelementptr { i32, i32 }, ptr %x, i32 0, i32 1
> %t3 = getelementptr { i32, i32 }, ptr %y, i32 0, i32 1
> %t4 = icmp eq ptr %t1, %t3
> ret i1 %t4
> }
> ```
>
> The crash report indicates assertion failure in `APInt.h` within `setBit()`. It appears to be caused by the fact that for `ptr` types, bit size is reported as 0, so later in the matching code, a call to `APInt::getOneBitSet` essentially asks for a number that has 0 bits, with bit #0 set. I'm unsure if I should simply ignore cases like this (e.g. by adding `if (Op0->getType()->getScalarSizeInBits() == 0) return nullptr`), or if there's a nicer/more usual way of handling this?
I'd say just handle the splat vector case for now. If #85676 gets in before this, you could use that API.
https://github.com/llvm/llvm-project/pull/85555
More information about the llvm-commits
mailing list