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: [PTR-PLUS] Add/fix documentation for POINTER_PLUS_EXPR

On 5/8/07, Zdenek Dvorak <> wrote:

> >  I figured as much that I needed to update the documentation for the
> >addition of POINTER_PLUS_EXPR.  This patch does that and fixes one small
> >documentation in tree.def about the second operand.
> The "small fix", documenting the 2nd operand of POINTER_PLUS_EXPR
> to be always unsigned instead of signed makes me curious.  This effectively
> means that POINTER_PLUS_EXPR overflow is defined as wrapping, which
> will make some transformations we do now invalid and complicates
> re-construction of array accesses &a p+ CST to &a[CST/element_size]
> where this division needs to be done as signed.
> So I would have thought an always signed representation of the
> 2nd operand would have been a more natural choice.
> Any clarifications on why you came to this conclusion?

actually, I have tried also using ssizetype, which indeed appears more
natural.  I run into problems in scev, though.  The serious one is the
following: consider architecture where both pointers and ints are 32
bit, and the following loop:

int *p;

for (unsigned i = 0; ; i++)
    t1 = (ssizetype) i;
    t2 = 4 * t1;
    t3 = p (pplus) t2;
    use (*t3);

the evolution of i is [0,+,1].  The problem is that it is somewhat hard to
derive that the evolution of t1 is also [0,+,1] (in ssizetype) -- in
ssizetype the overflow is undefined, so we may do that only in case when
we are sure the loop iterates less than 2^31 times.

Of course, the way the pointer arithmetics in the loop is done ensures
that the loop iterates less than 2^29 times, but to derive this, we would
need to know the evolution of t2, and for that we need to know the
evolution of t1, at which point we are stuck.  There are various ways
out of this chicken-and-egg loop, but I do not see an easy and reliable
one (if someone did, I would be very grateful).

No, I don't see an easy way around this problem. But won't using unsigned sizetype cause some problems with number-of-iterations analysis as well?

But of course not being able to fold

if (p (pplus) 4 > p (pplus) -4)

doesn't look like a better problem to solve.

Now, if we can interpret the 2nd argument of pplus as signed or unsigned
as we like (one could say pointers are neither signed nor unsigned, so
we can choose, and as long as we do consistently we _can_ fold the
above).  We should at least try to nail some of this issues down in the


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