[llvm] [ValueTracking] Compute known bits for `umin` and `umax` recurrences (PR #222890)

Ömer Sinan Ağacan via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 17 03:51:11 PDT 2026


osa1 wrote:

@nikic based on the code that I want to optimize: we have a loop with `umin` and/or `umax` and the computed values end up in a `trunc` to a smaller type. In these cases, for the computation to be done on a smaller type, we need to know high zeros. For high zeros, the code for `umin` is:
```
Known.Zero.setHighBits(KnownStart.countMinLeadingZeros());
```
This is because the minimum loops start with a high value (e.g. 255) and then go lower, so the start value gives you the min. number of zeros.

But for `umax` you need to analyse both `Start` and `Step` for the same analysis:
```
Known.Zero.setHighBits(std::min(KnownStart.countMinLeadingZeros(),
                                KnownStep.countMinLeadingZeros()));
```
Once you analyse both branches it's easy to just also do:
```
Known.One.setHighBits(KnownStart.countMinLeadingOnes());
```

Whereas the same thing in `umin` case would require analysing `Step`, which we don't need to do to optimize `umin`/`umax` loops ending in a `trunc`.

It's straightforward to make them symmetric, it can just add costs and I'm not aware of any code that'd benefit from it.

lmk if you still want me to update the `umin` handling with the symmetric code.

(The follow-up PR https://github.com/llvm/llvm-project/pull/222914 does the optimization, this branch just updates the analysis part)

https://github.com/llvm/llvm-project/pull/222890


More information about the llvm-commits mailing list