From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42963 invoked by alias); 12 Apr 2017 17:06:46 -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 42214 invoked by uid 89); 12 Apr 2017 17:06:45 -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=das 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 ESMTP; Wed, 12 Apr 2017 17:06:44 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 847F3C05167B; Wed, 12 Apr 2017 17:06:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 847F3C05167B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 847F3C05167B Received: from tucnak.zalov.cz (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 12EC619E7E; Wed, 12 Apr 2017 17:06:43 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v3CH6fCK023409; Wed, 12 Apr 2017 19:06:41 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v3CH6c8K023408; Wed, 12 Apr 2017 19:06:38 +0200 Date: Wed, 12 Apr 2017 17:06:00 -0000 From: Jakub Jelinek To: Sudi Das Cc: "gcc-patches@gcc.gnu.org" , Marcus Shawcroft , Richard Earnshaw , James Greenhalgh , nd Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x) Message-ID: <20170412170638.GA1809@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00590.txt.bz2 On Wed, Apr 12, 2017 at 09:29:55AM +0000, Sudi Das wrote: > Hi all > > This is a fix for PR 80131 > Currently the code A << (B - C) is not simplified. > However at least a more specific case of 1U << (C -x) where C = precision(type) - 1 can be simplified to (1 << C) >> x. Is that always a win though? Some constants have higher costs than others on various targets, some significantly higher. This change might be beneficial only if if C is as expensive as 1, then you get rid of a one (typically cheap) operation. Which makes me wonder whether this should be done at GIMPLE time and not at RTL time (expansion or combine etc.) when one can compare the RTX costs. Or do this at match.pd as canonicalization and then have RTL transformation to rewrite such (1U << C) >> X as 1U << (C - X) if the latter is faster (or shorter). Jakub