This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tree-vrp.c: Compute a correct range when adding twopointers.
- From: Jeffrey A Law <law at redhat dot com>
- To: Kazu Hirata <kazu at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, dnovillo at redhat dot com
- Date: Thu, 23 Jun 2005 09:29:09 -0600
- Subject: Re: [patch] tree-vrp.c: Compute a correct range when adding twopointers.
- References: <200506231511.j5NFBSrS029224@sethra.codesourcery.com>
- Reply-to: law at redhat dot com
On Thu, 2005-06-23 at 08:11 -0700, Kazu Hirata wrote:
> Attached is a patch to compute a correct range when adding two pointers.
> foo (int *p, int q)
> if (p == 0)
> if (q == 0)
> int *r = &p[q];
> if (r != 0)
> link_error ();
> After passing the first two "if" statements, we know that p and q are
> both 0, so r, which is really &p[q], must also be 0. However, VRP
> thinks that an addition of two pointers *always* results in nonnull,
> which isn't true.
> The patch fixes this problem by examing the value ranges of a
> PLUS_EXPR's operands. If either one is nonnull, the result is
> nonnull. If both are null, the result is obviously null. Otherwise,
> the result is VR_VARYING.
> Tested on x86_64-pc-linux-gnu. OK to apply?
Does this ever happen in practice? While I can follow the reasoning
which leads to a non-null result for R, I have a hard time seeing
this happening often enough in real code to matter.
If you want to do something interesting with VRP you might look at
extracting ranges from BIT_AND_EXPRs -- that's relatively common and
can often lead to further optimizations, particularly when the
BIT_AND_EXPR turns off the sign bit or constrains a result to a