From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1565 invoked by alias); 24 Apr 2013 15:13:31 -0000 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 Received: (qmail 1511 invoked by uid 89); 24 Apr 2013 15:13:31 -0000 X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 24 Apr 2013 15:13:29 +0000 Received: by mail-ie0-f177.google.com with SMTP id 9so2146766iec.8 for ; Wed, 24 Apr 2013 08:13:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.187.225 with SMTP id fv1mr22704073igc.74.1366816408242; Wed, 24 Apr 2013 08:13:28 -0700 (PDT) Received: by 10.64.7.37 with HTTP; Wed, 24 Apr 2013 08:13:28 -0700 (PDT) In-Reply-To: <87txmwm0r9.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> References: <506C72C7.7090207@naturalbridge.com> <50891AAC.8090301@naturalbridge.com> <87y5im3orb.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <87pq3y3kyk.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <50912D85.1070002@naturalbridge.com> <5091331C.3030504@naturalbridge.com> <512D686B.90000@naturalbridge.com> <515EC4E7.7040907@naturalbridge.com> <871ua0qer8.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <87y5c8nhz2.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <87fvygngsw.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <87txmwm0r9.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> Date: Wed, 24 Apr 2013 16:51:00 -0000 Message-ID: Subject: Re: patch to fix constant math -5th patch, rtl From: Richard Biener To: Richard Biener , Kenneth Zadeck , Mike Stump , gcc-patches , Lawrence Crowl , Ian Lance Taylor , rdsandiford@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-04/txt/msg01447.txt.bz2 On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford >> wrote: >>> In other words, one of the reasons wide_int can't be exactly 1:1 >>> in practice is because it is clearing out these mistakes (GEN_INT >>> rather than gen_int_mode) and missing features (non-power-of-2 widths). >> >> Note that the argument should be about CONST_WIDE_INT here, >> not wide-int. Indeed CONST_WIDE_INT has the desired feature >> and can be properly truncated/extended according to mode at the time we build it >> via immed_wide_int_cst (w, mode). I don't see the requirement that >> wide-int itself is automagically providing that truncation/extension >> (though it is a possibility, one that does not match existing behavior of >> HWI for CONST_INT or double-int for CONST_DOUBLE). > > I agree it doesn't match the existing behaviour of HWI for CONST_INT or > double-int for CONST_DOUBLE, but I think that's very much a good thing. > The model for HWIs at the moment is that you have to truncate results > to the canonical form after every operation where it matters. As you > proved in your earlier message about the plus_constant bug, that's easily > forgotten. I don't think the rtl code is doing all CONST_INT arithmetic > on full HWIs because it wants to: it's doing it because that's the way > C/C++ arithmetic on primitive types works. In other words, the current > CONST_INT code is trying to emulate N-bit arithmetic (for gcc runtime N) > using a single primitive integer type. wide_int gives us N-bit arithmetic > directly; no emulation is needed. Ok, so what wide-int provides is integer values encoded in 'len' HWI words that fit in 'precision' or more bits (and often in less). wide-int also provides N-bit arithmetic operations. IMHO both are tied too closely together. A give constant doesn't really have a precision. Associating one with it to give a precision to an arithmetic operation looks wrong to me and are a source of mismatches. What RTL currently has looks better to me - operations have explicitely specified precisions. > If your point is that an arbitrary-precision wide_int could be used by > other (non-rtl, and probably non-tree) clients, then I don't really > see the need. We already have mpz_t for that. What we don't have, > and what we IMO need, is something that performs N-bit arithmetic > for runtime N. It seems better to have a single class that does > that for us (wide_int), rather than scatter N-bit emulation throughout > the codebase, which is what we do now. mpz_t is not suitable here - it's way too expensive. double-int was the "suitable" bit for now, but given it's host dependency and inability to handle larger ints (VRP ...) the ability to use wide-ints for this looks appealing. Richard. > Richard