Preserve pointer types in ivopts

[Richard Guenther]

On Fri, Mar 16, 2012 at 2:37 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 03/16/2012 02:33 PM, Zdenek Dvorak wrote:
>>>>> Yes, that could work. ?Though it might end up being incredibly ugly ;)
>>>>
>>>> In the code? Should really only change a few lines in the patch I would
>>>> have thought. I'll get back to you when I have a new version - thanks
>>>> for the tip.
>>>
>>> No, in the GIMPLE IL.
>>>
>>> Richard.
>>
>> And I can just imagine how happy would other optimizations be about such a change.
>> Are we speaking about something that you would like to get into mainline?
>> All of this looks like a lot of hacks to deal with a rather weird target.
>
> The final piece - using &TARGET_MEM_REF rather than POINTER_PLUS_EXPR to
> avoid overflow issues - is clearly a bit of a hack. But otherwise,
> keeping around the proper types rather than casting everything to
> unsigned int is IMO much less ugly and hackish than what we have now.
> Certainly the gimple IL is much less cluttered after the patch than before.

Btw, at one point I thought we might use Pmode integer types as base
"pointer" types for [TARGET_]MEM_REF.  But of course your target
shows that this might not be a good idea.

We do have three pointer offsetting operations at the moment,
POINTER_PLUS_EXPR, &MEM_REF and &TARGET_MEM_REF.
All of which expect C pointer semantics (if they can see the base
pointer, which is why I suggested to create a TARGET_MEM_REF
with a NULL pointer TMR_BASE and shove the base pointer to
TMR_INDEX2 (which incidentially needs to be an integer type ...).

In the end what we want is a POINTER_PLUS_EXPR variant
that does not make alias-analysis assume the result still points
to within the objects the pointer pointed to before the increment/decrement.

Btw, how do you handle pointer differences?  The frontend already
lowers them to (intptr_t)ptr1 - (intptr_t)ptr2.

Richard.

> Bernd