From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4878 invoked by alias); 24 Apr 2013 14:53:22 -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 4868 invoked by uid 89); 24 Apr 2013 14:53:22 -0000 X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1 Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com) (209.85.214.178) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 24 Apr 2013 14:53:12 +0000 Received: by mail-ob0-f178.google.com with SMTP id 16so1590941obc.9 for ; Wed, 24 Apr 2013 07:53:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=j4HyM34P6Vva/hLvGN7sj0riYhaulfkWtmoZifs8IMg=; b=HykwrNWc6Ne68OFPPUarJeE8EYvMSnobWk7Ycmrbaee66cG9VG4cgEVDX/WJBYVXiS r9dXawDZkNp07UAtL3Ogv2XNCYaHjcVnd31S499IYBlihw8HGRPW+L+zaj780mRnYvxh qe/4ygY6kUzDPIo4SRYiqHbU/CTtXJU0kSFimY1+DS2jcyx44hx1OH2xaRa+H3R3f3Lq 1XfB859m7Ovs5aB7DQ7jONeDsDex+IoSgJuMJWJENTJ/U/CwCGLkkwEw3Rcb4m5/4hqH 2Z1qcc6nRsWuXLlmAFqCkPx4a6XQKHti1/mYggFsY7ZPCJWtIvy5T0hNE0PIKp9vGeRw mqWw== X-Received: by 10.60.33.105 with SMTP id q9mr17217847oei.54.1366815191322; Wed, 24 Apr 2013 07:53:11 -0700 (PDT) Received: from ?IPv6:2001:468:913:2044:ec1e:c8ba:60c9:c249? ([2001:468:913:2044:ec1e:c8ba:60c9:c249]) by mx.google.com with ESMTPSA id t9sm1126460obk.13.2013.04.24.07.53.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 07:53:10 -0700 (PDT) Message-ID: <5177F1D4.7060405@naturalbridge.com> Date: Wed, 24 Apr 2013 15:13:00 -0000 From: Kenneth Zadeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Biener CC: Mike Stump , gcc-patches , Lawrence Crowl , Ian Lance Taylor , rdsandiford@googlemail.com Subject: Re: patch to fix constant math -5th patch, rtl References: <506C72C7.7090207@naturalbridge.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> <516DB1F3.8090908@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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn4TXSgelDnbKLpfg4CESALQGxEntkWorpYItFJPTHiiJa5pQa0T60p8gbxV7RARkto0v04 X-SW-Source: 2013-04/txt/msg01435.txt.bz2 On 04/24/2013 10:42 AM, Richard Biener wrote: > On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> I suppose the above should use immed_double_int_const (v, mode), too, >> In practice it doesn't matter, because... >> >>> which oddly only ever truncates to mode for modes <= HOST_BITS_PER_WIDE_INT >>> via gen_int_mode. >> ...right. That's because there's not really any proper support for >> non-power-of-2 modes. Partial modes like PDI are specified by things like: >> >> PARTIAL_INT_MODE (DI); >> >> which is glaringly absent of any bit width. So if the constant is big >> enough to need 2 HWIs, it in practice must be exactly 2 HWIs wide. > Ah, of course. > >> One of the advantages of wide_int is that it allows us to relax this >> restriction: we can have both (a) mode widths greater than >> HOST_BITS_PER_WIDE_INT*2 and (b) mode widths that are greater than >> HOST_BITS_PER_WIDE_INT while not being a multiple of it. >> >> 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). > > Richard. > yes but you still have the problem with partial ints having no length. Our plan was to be very careful and make sure that at no point were we doing anything that makes it harder to put modes in const_ints, but that is different from going thru everything and doing it. Partially because of this discussion and some issues that you brought up with patch 4, i am removing the trick of being able to say 'wi + rtl' because there is no mode for the rtl. i am leaving the 'wi + tree' because there is enough to info in the treecst to make this work. but you are going to have to say something wi::add (mode, rtl) see, i am willing to do things that work better in the tree world than in the rtl world. kenny >> Richard