During the guard widening we can add a poison use in the first guard which
can result in undefined behavior which were not before due to this guard could
guards us from it.
To protect us we could use logical and instead of arithmetic and as it states in
widenCondCommon.
This is alternative solution to https://reviews.llvm.org/D128155.
What worries me is that usage of select may break parseRangeChecks logic
where it expects arithmetic and to split already widened condition...
m_LogicalAnd also matches m_And, so you can drop the code above.