On Fri, Mar 16, 2012 at 2:37 PM, Bernd Schmidt <ber...@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
