[llvm] [InstCombine] Fold (X / C) < X and (X >> C) < X into X > 0 (PR #85555)

[via llvm-commits]

goldsteinn wrote:

> Updated proofs (26 in total) can be found [here](https://alive2.llvm.org/ce/z/TDRxuG). I've fixed most of the issues mentioned here, the only two things I'm worried about are: 1.The current code does not work with vector constants that have different values in each component (e.g. take a look at test case `lshr_by_const_cmp_sle_value`). I believe this is caused by `m_APInt` not matching when a vector constant has different components, but I am unsure about that. Can something be done about this or should I leave this particular scenario unaffected by the optimization? 

Yes that is one of the drawbacks of APInt, it only match if the vector is a splat (all elements that same).
You could use: `m_SpecificInt_ICMP` (see PatternMatch.h).
So for the div cases: `m_SpecificInt_ICMP(ICmpInst::ICMP_UGT, APInt::getOneBitSet(Op0->getType()->getScalarSizeInBits(), 1))` (not the cleanest API to use).

> 2. It appears that `lshr` already has a similar fold implemented, since test case `lshr_by_const_cmp_ule_value` was not affected by the changes that I've made (it folded to `ret i1 true` both before and after the changes to the code). Can someone confirm that this is the case, and if so, should I remove the `lshr` code path from my PR?

See: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/InstructionSimplify.cpp#L3172
No need to go out of your way to avoid that case. Its not extra code on your end to handle (and its correct). I wouldn't use it as a test, however, as its not going through your code path.

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