On 2/12/25 8:18 AM, Jakub Jelinek wrote:
On Tue, Feb 11, 2025 at 05:20:49PM -0700, Jeff Law wrote:
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_OVERFLOW IFN to statically compute the overflow state and ultimately
allow turning the IFN into simple arithmetic (or for the tests in this BZ
elide the arithmetic entirely).
The regression example is when the two inputs are known equal. In that case
the subtraction will never overflow. But there's a few other cases we can
handle as well.
a == b -> never overflows
a > b -> never overflows when A and B are unsigned
a >= b -> never overflows when A and B are unsigned
a < b -> always overflows when A and B are unsigned
Is that really the case?
I mean, .SUB_OVERFLOW etc. can have 3 arbitrary types, the type into which
we are trying to write the result and the 2 types of arguments.
So if the types are allowed to vary within a statement (I guess as an
IFN they can unlike most gimple operations).
In which case we'd need to tighten the checks. THe simplest would be to
ensure that both arguments have the same/equivalent types. We could go
farther than that, though the risk/benefit of doing more may not be great.
I'll digest the rest a bit later, but clearly pushing pause while I do so...
jeff
