From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97191 invoked by alias); 26 Jan 2016 19:17:33 -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 97180 invoked by uid 89); 26 Jan 2016 19:17:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1859, truth, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 26 Jan 2016 19:17:30 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 66979106F; Tue, 26 Jan 2016 19:17:28 +0000 (UTC) Received: from tucnak.zalov.cz ([10.3.113.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0QJHQj7031062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jan 2016 14:17:27 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u0QJHO22031015; Tue, 26 Jan 2016 20:17:24 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u0QJHMXX030948; Tue, 26 Jan 2016 20:17:22 +0100 Date: Tue, 26 Jan 2016 19:17:00 -0000 From: Jakub Jelinek To: Mike Stump Cc: Richard Sandiford , Richard Biener , "H.J. Lu" , GCC Patches Subject: Re: [PATCH] Fix up wi::lrshift (PR c++/69399) Message-ID: <20160126191722.GG3017@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160122185533.GA3430@intel.com> <20160126182148.GE3017@tucnak.redhat.com> <4ADD4937-E19F-4CD0-8441-C97935548759@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4ADD4937-E19F-4CD0-8441-C97935548759@comcast.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg02022.txt.bz2 On Tue, Jan 26, 2016 at 11:00:52AM -0800, Mike Stump wrote: > On Jan 26, 2016, at 10:21 AM, Jakub Jelinek wrote > > The question is, shall we do what wi::lshift does and have the fast path > > only for the constant shifts, as the untested patch below does, or shall we > > check shift dynamically (thus use > > shift < HOST_BITS_PER_WIDE_INT > > instead of > > STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT) > > in the patch), > > Hum… I think I prefer the dynamic check. The reasoning is that when we > fast path, we can tolerate the conditional branch to retain the fast path, > as most of the time, that condition will usually be true. If the compiler > had troubles with knowing the usual truth value of the expression, seems > like we can hint that it will be true and influence the static prediction > of the branch. This permits us to fast path almost all the time in the > non-constant, but small enough case. For known shifts, there is no code > gen difference, so it doesn’t matter. Ok, I've cancelled my pending bootstrap/regtest and am testing this instead: 2016-01-26 Jakub Jelinek PR tree-optimization/69399 * wide-int.h (wi::lrshift): For larger precisions, only use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT. --- gcc/wide-int.h.jj 2016-01-04 18:50:34.656471663 +0100 +++ gcc/wide-int.h 2016-01-26 20:07:03.147054988 +0100 @@ -2909,7 +2909,9 @@ wi::lrshift (const T1 &x, const T2 &y) For variable-precision integers like wide_int, handle HWI and sub-HWI integers inline. */ if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT) - ? xi.len == 1 && xi.val[0] >= 0 + ? (shift < HOST_BITS_PER_WIDE_INT + && xi.len == 1 + && xi.val[0] >= 0) : xi.precision <= HOST_BITS_PER_WIDE_INT) { val[0] = xi.to_uhwi () >> shift; Jakub