[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