From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-301331-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9864 invoked by alias); 3 Sep 2011 21:20:17 -0000
Received: (qmail 9856 invoked by uid 22791); 3 Sep 2011 21:20:16 -0000
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213)    by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sat, 03 Sep 2011 21:20:03 +0000
Received: by vlsi1.ultra.nyu.edu (4.1/1.34)	id AA29161; Sat, 3 Sep 11 17:19:58 EDT
From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Message-Id: <11109032119.AA29161@vlsi1.ultra.nyu.edu>
Date: Sat, 03 Sep 2011 21:20:00 -0000
To: richard.guenther@gmail.com
Subject: Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1
Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, rguenther@suse.de
In-Reply-To: <CAFiYyc3c0fT2KvM2JjaJFuvZV3nzGnKQU7rFV6v9f9D2c8_ufQ@mail.gmail.com>
References: <alpine.LNX.2.00.1108311055480.2130@zhemvz.fhfr.qr>    <201109031124.37807.ebotcazou@adacore.com>    <CAFiYyc22YMnd+iSQt8ABV5upM+w_nq8iZq8-2eNjBO4dO+kcYA@mail.gmail.com>    <201109031708.52403.ebotcazou@adacore.com>    <CAFiYyc3t8FDAVwv+wVPbpm0pESyQCvEdRQoQm-pk9sMLwKdm_Q@mail.gmail.com>    <11109031947.AA28670@vlsi1.ultra.nyu.edu>    <CAFiYyc3c0fT2KvM2JjaJFuvZV3nzGnKQU7rFV6v9f9D2c8_ufQ@mail.gmail.com>
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-09/txt/msg00233.txt.bz2

> So what's your opinion on the "bug" that triggered the patch in question?
> Namely extract_muldiv_1 folding
> 
> (((10240 - (sizetype) first) + 1) * 8) /[cl] 8
> 
> to
> 
> ((sizetype) first * 0x0fffffffffffffff8 + 81928) /[cl] 8
> 
> to
> 
> ((sizetype) first * 2305843009213693951 + 10241)
> 
> thus, folding A - B to -B + A, which is valid for unsigned types only
> if overflow wraps. 

I think the tricky part is the optimization of (-X) * 8 to (-8 * X),
especially if you then try to compute the -8 as unsigned.  I don't think
that's valid no matter what overflow does, but I still have a hard time
reasoning about these things.

> Can you give a formal definition of sizetype behavior that can be
> used to prove that both transforms are valid?

No, that's what I said before: I don't now have and never did have a formal
definition.  Which was not good.