Even if we know nothing about LHS, it can still be useful to know that

smax(LHS, RHS) >= RHS and smin(LHS, RHS) <= RHS.

# Details

# Diff Detail

- Repository
- rG LLVM Github Monorepo

### Event Timeline

N.B without D87034, this change wouldn't affect any codegen tests. So this is one case where the improved known bits analysis actually makes a difference.

llvm/test/CodeGen/X86/avx512-trunc.ll | ||
---|---|---|

1020 | Is this testing what it means to? I can't remember offhand what the test is for - @craig.topper any ideas? | |

llvm/test/CodeGen/X86/masked_store_trunc_usat.ll | ||

5199 ↗ | (On Diff #289963) | regression? |

6420 ↗ | (On Diff #289963) | regression? |

llvm/test/CodeGen/X86/vector-trunc-usat.ll | ||

4266 ↗ | (On Diff #289963) | we appear to have 3 constant loads now instead of 2 |

llvm/test/CodeGen/X86/avx512-trunc.ll | ||
---|---|---|

1020 | Not sure either. InstCombine simplifies it to a store of all ones. |

llvm/test/CodeGen/X86/masked_store_trunc_usat.ll | ||
---|---|---|

5199 ↗ | (On Diff #289963) | Wel, yes... It has spotted that the result of the pminsw is always negative, so rather than XOR with 0x8000 to flip (i.e. clear) the sign bit, it can AND with 0x7fff to clear the sign bit. But unfortunately that means materialising another constant. I don't know where this XOR -> AND "optimization" happens, or whether it can be finessed. The other regressions you pointed out below are basically the same issue. |

llvm/test/CodeGen/X86/masked_store_trunc_usat.ll | ||
---|---|---|

5199 ↗ | (On Diff #289963) |
We have done this basically forever, in the XOR case in TargetLowering::SimplifyDemandedBits: // If one side is a constant, and all of the known set bits on the other // side are also set in the constant, turn this into an AND, as we know // the bits will be cleared. // e.g. (X | C1) ^ C2 --> (X | C1) & ~C2 iff (C1&C2) == C2 It seems to me that this is just bad luck, that we transform X^0x8000 into X&0x7FFF, but that happens to regress code quality because now we can't share with another use of the constant 0x8000. Is there any systematic way of fixing this, e.g. by doing the reverse transformation once we know what constants are already available in registers? Or can I commit this patch even with a known regression like this? After all, I'm sure if I looked hard enough I could find another test that got better by luck instead of worse. |

llvm/test/CodeGen/X86/masked_store_trunc_usat.ll | ||
---|---|---|

5199 ↗ | (On Diff #289963) |

llvm/test/CodeGen/X86/avx512-trunc.ll | ||
---|---|---|

1020 | The test was added as part of D45315 - @ArturGainullin hasn't been an active for some time afaict. I think we might be able to get away with adjusting the -1 splat to be a non-uniform mix of -ve constant values. |

llvm/test/CodeGen/X86/avx512-trunc.ll | ||
---|---|---|

1020 | Any recommendations on what to do with these tests? |

@foad Please can you rebase? I think I've replaced the dodgy test with something useful now