On Wed, Feb 12, 2025 at 08:29:37AM -0700, Jeff Law wrote:
> 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).
The overflow builtins started from clang's
__builtin_{s,u}{add,sub,mul}{,l,ll}_overflow
builtins (those were added for compatibility), all of those have the 3 types
identical; but the __builtin_{add,sub,mul}_overflow{,_p} builtins allow 3
arbitrary types, whether something overflows or not is determined by
performing the operation in virtually infinite precision and then seeing if
it is representable in the target type.
I'm fine if your patch is for GCC 15 limited to the easy cases with all 3
types compatible (that is the common case). Still, I think it would be nice
not to restrict to TYPE_UNSIGNED, just say check either that for a >= b or a > b
b is not negative (using vr1min).
And let's file a PR for GCC 16 to do it properly.
Jakub
