From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6739 invoked by alias); 2 Sep 2013 12:43:55 -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 6725 invoked by uid 89); 2 Sep 2013 12:43:54 -0000 Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Sep 2013 12:43:54 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.2 X-HELO: mail-ie0-f174.google.com Received: by mail-ie0-f174.google.com with SMTP id k14so7890959iea.19 for ; Mon, 02 Sep 2013 05:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lXAaLbkJKJP3e0XSMLz1KDMXgy1wjihe057nx4DC8Gs=; b=T5cRiLQOwAeeQLv1Nqj/uweNu/gXcbohTS1dh2mpGTqM3AzvuZziommJQkVLAs6KaC 6jeQC/Z/2qVtVIJQXZzcPCafdVdyQIB4XQztuNEHKamLtQ+rcGFQNJKL9O9KgJ/eZbHd 3wg+xO30tk/IdJJpzBImhb1YRdaqKEZT6VHFtHsnPGDtdLUHeEUlPhDUni/nULcsGBl9 hQrRRWyEo0xkuvj7FlOBqTh+0+arJizvPlJUueZnafYRB66FgUldNM08yLyBbed54dVm 8/IG7hu+wOZWw5H/Xc3nk33Q+DbXbrbU5NfafdZLJW6DhyGHHX0kqFhaMMf2Eas5s4a3 MHcw== X-Gm-Message-State: ALoCoQkEkjyewnmc+sNwci/tJfjIK4lH7OPt74q7ATp2eAUiYIZT1GCujkDrC0K+08Xqz53/vI2G X-Received: by 10.50.65.99 with SMTP id w3mr3236825igs.42.1378125831702; Mon, 02 Sep 2013 05:43:51 -0700 (PDT) Received: from moria.site (pool-98-113-157-218.nycmny.fios.verizon.net. [98.113.157.218]) by mx.google.com with ESMTPSA id i1sm17617500iga.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 05:43:51 -0700 (PDT) Message-ID: <52248806.7040205@naturalbridge.com> Date: Mon, 02 Sep 2013 12:43:00 -0000 From: Kenneth Zadeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Biener CC: Richard Sandiford , gcc-patches@gcc.gnu.org, mikestump@comcast.net Subject: Re: [RFC] Changes to the wide-int classes References: <87wqn0bb5q.fsf@talisman.default> <5223F9D7.1030307@naturalbridge.com> <87ioyjbncu.fsf@talisman.default> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00067.txt.bz2 On 09/02/2013 05:35 AM, Richard Biener wrote: > On Mon, 2 Sep 2013, Richard Sandiford wrote: > >> Kenneth Zadeck writes: >>> There is no place for exactly two HWIs in the machine independent parts >>> of the compiler, >> I totally agree. In fact I was taking that so much for granted that >> I didn't even think to add a rider about it, sorry. I didn't mean >> to imply that we should keep double_int around. >> >> I think the reason for doing this is to prove that it can be done >> (so that the wide_int code isn't too big a change for the tree level) >> and to make it easier to merge the wide-int patches into trunk piecemeal >> if we need to. > Note that changing the tree rep to non-double_int is easy. Also note > that I only want 'double_int' to stay around to have a fast type > that can work on two HWIs for the code that need more precision > than a HWI. The only important cases I know of are in > get_inner_reference and get_ref_base_and_extent and friends. Those > are heavily used (and the only double-int function callers that > even show up in regular cc1 profiles). > > So if wide_int_fixed<2> ('2' better be replaced with > 'number-that-gets-me-twice-target-sizetype-precision') > works for those cases then fine (and we can drop double-ints). This is what the addr_wide_int is for - it sniffs the port and is guaranteed to big enough to hold the largest pointer, + 4 bits (3 bits for bitposition and 1 bit so that unsigned things come over with no loss) then that is rounded up to the next hwi. (i will admit that the sniffing code needs a little work but that can be fixed without changing the api). kenny