On Fri, Mar 16, 2012 at 1:13 AM, Andrew Pinski <pins...@gmail.com> wrote:
> On Thu, Mar 15, 2012 at 5:09 PM, Bernd Schmidt <ber...@codesourcery.com> 
> wrote:
>> On 03/16/2012 12:44 AM, Jakub Jelinek wrote:
>>> For pointer arithmetics in the IL we assume the C
>>> requirements, pointer arithmetics can be performed only within the same
>>> object, so for
>>> int a[10];
>>> both of the following are invalid, even in the IL:
>>> int *p = a - 1;
>>> int *q = a + 11;
>> Ok, so what's the solution? Add a second POINTER_PLUS_EXPR code with
>> defined overflow behaviour, or add a flag to it?
> We should have one for PLUS_EXPR also.  There was some movement on
> that on a branch that Richard Guenther did but I don't know if he is
> going to work on it further.  I have been noticing more and more the
> need for this feature while working on my tree combiner branch, that I
> might try to see if Richard's branch can be revisited.

The branch was a too big task at one time, so presently I'm trying to get rid
of the speciality of "sizetypes" first and then plan to revisit the branch.  To
recap - on the branch we have an explicit notion on whether a operation
can overflow or not (where "not overflowing" is equivalent to "undefined
behavior if overflow happens").  Operations are marked either way by
choosing different tree codes.

See http://gcc.gnu.org/wiki/NoUndefinedOverflow

Unfortunately updating the branch stopped before tuplification (heh ...).
So I guess it will need to be re-done from start.  And yes, it's a massive
effort.  But in theory you can do the massaging incrementally - so, in
your case add only POINTER_PLUSNV_EXPR and make sure to
drop that to POINTER_PLUS_EXPR whenever you are no longer sure
that the operation follows the C language constraints of pointer arithmetic
(and change all folders that assume that semantic to work only on
POINTER_PLUSNV_EXPRs).  Or do it the other way around (which of
course will be less conservatively correct - something I'm no longer 100%
sure about).

Your patch as-is is not safe at the moment.  But why is casting a pointer
to an integer prohibitly expensive?  That fact should be an implementation
detail of GIMPLE.  Or is it the issue that IVOPTs chooses an integer
type that does not necessarily match the mode we'll use on RTL?
(thus, ptr_mode vs. Pmode issues, and/or sizeof (sizetype) != sizeof (void *)


Reply via email to