On Thu, Jun 30, 2016 at 3:38 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
> On Thu, 30 Jun 2016, Manish Goregaokar wrote:
>
>> Alright, the following patch was tested and it works
>>
>> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
>> index 3b9500d..0d82018 100644
>> --- a/gcc/fold-const.c
>> +++ b/gcc/fold-const.c
>> @@ -13199,6 +13199,9 @@ tree_binary_nonzero_warnv_p (enum tree_code code,
>> switch (code)
>> {
>> case POINTER_PLUS_EXPR:
>> + return flag_delete_null_pointer_checks
>> + && (tree_expr_nonzero_warnv_p (op0, strict_overflow_p)
>> + || tree_expr_nonzero_warnv_p (op1, strict_overflow_p));
>> case PLUS_EXPR:
>> if (ANY_INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_UNDEFINED (type))
>> {
>
>
> So, what prevents us from deciding that p+(0-p) is nonzero when p is? Not
> sure if it is strictly legal in all languages, but I wouldn't be surprised
> if there was at least one language where optimizations could lead to such
> expressions.
>
> I think this is an exciting optimization, but I was always too scared to try
> anything like this.
;)
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).
Richard.
> --
> Marc Glisse
