This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] tree-vrp.c: Compute a correct range when adding twopointers.

On Thu, 2005-06-23 at 08:11 -0700, Kazu Hirata wrote:
> Hi,
> Attached is a patch to compute a correct range when adding two pointers.
> Consider
> void
> 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 
smaller type.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]