From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1890 invoked by alias); 3 Sep 2011 20:39:27 -0000 Received: (qmail 1882 invoked by uid 22791); 3 Sep 2011 20:39:26 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Sep 2011 20:39:10 +0000 Received: by ywa12 with SMTP id 12so2843929ywa.20 for ; Sat, 03 Sep 2011 13:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.49.8 with SMTP id b8mr1869320ybk.394.1315082349700; Sat, 03 Sep 2011 13:39:09 -0700 (PDT) Received: by 10.151.84.14 with HTTP; Sat, 3 Sep 2011 13:39:09 -0700 (PDT) In-Reply-To: References: <201109031124.37807.ebotcazou@adacore.com> <201109031708.52403.ebotcazou@adacore.com> <11109031947.AA28670@vlsi1.ultra.nyu.edu> Date: Sat, 03 Sep 2011 20:39:00 -0000 Message-ID: Subject: Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1 From: Richard Guenther To: Richard Kenner Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, rguenther@suse.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00230.txt.bz2 On Sat, Sep 3, 2011 at 10:37 PM, Richard Guenther wrote: > On Sat, Sep 3, 2011 at 9:47 PM, Richard Kenner > wrote: >> Let me jump in on this a little bit, since much of the code in this area >> was originally written by me. >> >>> Are all sizetype (sub-)expressions always of value in that range? >>> What do we do about the fact that sizetype is unsigned, so -x always >>> overflows for x !=3D 0? =A0Thus, do we need to disable all a - b -> a + >>> -b kind of foldings for sizetypes? (we don't) >> >> The basic idea is that an overflow of sizetype is either: >> >> (1) Detected at a higher level (e.g., testing for maximum sizes of objec= ts) or; >> (2) Is an undetected error and hence the result of such overflow is unde= fined. >> >> What this means from a practical point of view (but indeed a bit hard >> to define from a formal point of view) is that the normal addition and >> subtraction operations (on a 2's complement machines, which all are >> now) will "do the right thing" in all cases so we can perform all >> those sorts of folding operations. > > 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. =A0But the 2nd folding is only valid if overflow is un= defined. > Both foldings happen in extract_muldiv_1, the latter is especially > enabled for TYPE_IS_SIZETYPE. > > The reasoning why both transforms are valid is bogus IMHO. > Can you give a formal definition of sizetype behavior that can be > used to prove that both transforms are valid? And as you are here now, can you shed some light on the weird decision to make sizetype TYPE_UNSIGNED but sign-extended at the same time? ;) Richard. > Richard. >