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 *) issues?) Richard.
