On Thu, Jun 30, 2016 at 5:14 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
> On Thu, 30 Jun 2016, Richard Biener wrote:
>
>> points-to analysis already has the constraint that POINTER_PLUS_EXPR
>> cannot leave the object op0 points to. Of course currently nothing uses the
>> fact whether points-to computes pointed-to as nothing (aka NULL) - so the
>> argument may be moot.
>>
>> Anyway, one of my points to the original patch was that POINTER_PLUS_EXPR
>> handling should be clearly separate from PLUS_EXPR and that we have
>> flag_delete_null_pointer_checks to allow targest to declare that 0 is a
>> valid
>> object pointer (and thus you can do 4 + -4 and reach NULL).
>
>
> Thanks. So the tricky point is that we are not allowed to transform g into f
> below:
>
> char*f(char*p){return p+4;}
> char*g(char*p){return (char*)((intptr_t)p+4);}
>
> That makes sense and seems much easier to guarantee than I feared, nice.
>
> (on the other hand, only RTL is able to simplify (long)p+4-(long)(p+4))
Hmm, yeah - we have some match.pd stuff to handle these kind of cases,
like p + ((long)p2 - (long)p1)) and also (long)(p + x) - (long)p.
OTOH to handle (long)p + 4 - (long)(p + 4) the only thing we need is to
transform (long)(p + 4) to (long)p + 4 ... that would simplify things but
of course we cannot ever undo that canonicalization if the result is
ever converted back to a pointer. But maybe we can value-number it
the same with some tricks... (might be worth to file a bugreport)
Richard.
> --
> Marc Glisse
