This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Committed] PR26361: Handle unsigned NEGATE_EXPR in VRP
- From: Jeffrey A Law <law at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 21 Feb 2006 10:21:29 -0700
- Subject: Re: [Committed] PR26361: Handle unsigned NEGATE_EXPR in VRP
- References: <Pine.LNX.4.44.0602210814560.14787-100000@www.eyesopen.com>
- Reply-to: law at redhat dot com
On Tue, 2006-02-21 at 08:44 -0700, Roger Sayle wrote:
> On Tue, 21 Feb 2006, Diego Novillo wrote:
> > No, please try to make it generate [0, +INF].
> >
> > > I actually tried generating [0,+Inf] using TYPE_MIN_VALUE and
> > > TYPE_MAX_VALUE for min and max respectively, but this triggered
> > > an enable checking assert that didn't like ranges being set to
> > > these specific values.
> > >
> > You will need to figure this out.
>
> The problem is the asymmetry for integer types. [0,+Inf] is a
> valid range, but ~[0,+Inf] is not a valid anti-range.
Well, there's two cases I can think of, both would argue that
we really don't want ~[0, INF].
For unsigned values, ~[0, INF] is the empty set. Odds are if we're
creating an empty set range, then something bad has happened elsewhere.
For signed values, if an anti-range includes +INF or -INF, then the
anti-range is probably better represented as a true range. ie,
~[0, INF] should be represented as [-INF, -1]. Basically we need
to canonicalize the range.
I haven't studied this aspect of VRP well, but perhaps that's
why we reject ~[0, INF].
Jeff