From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32337 invoked by alias); 11 Feb 2015 16:06:52 -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 32314 invoked by uid 89); 11 Feb 2015 16:06:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Wed, 11 Feb 2015 16:06:47 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1BG6hLD030060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Feb 2015 11:06:44 -0500 Received: from tucnak.zalov.cz (ovpn-116-42.ams2.redhat.com [10.36.116.42]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1BG6f3X018752 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Feb 2015 11:06:43 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t1BG6e6P020717; Wed, 11 Feb 2015 17:06:40 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t1BG6cRR020716; Wed, 11 Feb 2015 17:06:38 +0100 Date: Wed, 11 Feb 2015 16:06:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: Richard Biener , Joseph Myers , GCC Patches Subject: Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing Message-ID: <20150211160638.GT1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <54CC560B.8080200@redhat.com> <54CDBDC6.3050000@redhat.com> <54CFBC2E.2040602@redhat.com> <54D076BC.9080504@redhat.com> <54DAFA05.5050804@redhat.com> <54DB7BA4.2030807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DB7BA4.2030807@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00724.txt.bz2 On Wed, Feb 11, 2015 at 08:56:20AM -0700, Jeff Law wrote: > On 02/11/15 04:16, Richard Biener wrote: > >> > >>Application of this pattern (and the one I posted for 47477) is a concern > >>for targets that don't do sub-word arithmetic/logicals. But I just did a > >>sniff test of one such target (v850-elf because it was handy) and I couldn't > >>spot a change in the end code using both the 47477 patch and my WIP patch > >>for this BZ. > > > >The c-family frontends perform this kind of narrowing already anyway > >(via the shorten_* stuff which is misplaced there and should be done > >elsewhere for all frontends - thus in match.pd, thanks for starting that). > True, but I wanted to see if there was any impact, but thankfully there > isn't. > > The fact that the C/C++ front-ends are doing most of the shortening now > probably explains why the fix for 47477 only affected code generation for > the Java front-end. The C/C++ FEs are doing it only if it appears on a single statement though, something fold can see at once. If you rewrite it so that there are multiple vars holding the intermediate values, they of course can't do that and it is a task for match.pd or specialized pass to handle those. Jakub