This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH PR c/71699] Handle pointer arithmetic in nonzero tree checks
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Manish Goregaokar <manish at mozilla dot com>, Pedro Alves <palves at redhat dot com>, Andrew Pinski <pinskia at gcc dot gnu dot org>
- Date: Thu, 30 Jun 2016 15:48:57 +0200
- Subject: Re: [PATCH PR c/71699] Handle pointer arithmetic in nonzero tree checks
- Authentication-results: sourceware.org; auth=none
- References: <CAFOnWk=xveuB-LNHHz4rE9+8vZK5yNfRPCTt5DUQs4ALdPKdtQ at mail dot gmail dot com> <CAFiYyc19Ap2kf4aWd-8Ebd-MYc2X6bubUs0h=iWNLr-w03aMpQ at mail dot gmail dot com> <CAFOnWkkLueeUeqCY3r3b-RTpJFXvsGOfCDyU3qeAqTJBvnVkhA at mail dot gmail dot com> <CAFiYyc15Aq0rcxSbzkxWY8Fs2HK6-wadv248tRKiYVGkxSZa4Q at mail dot gmail dot com> <CAFOnWknFZbBdpPm9h6tKLv4hwmKDW=68zimqom-eTbR4Lu=v9Q at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1606301529270 dot 2819 at laptop-mg dot saclay dot inria dot fr>
On Thu, Jun 30, 2016 at 3:38 PM, Marc Glisse <marc.glisse@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