From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56146 invoked by alias); 9 Nov 2015 09:51:44 -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 56126 invoked by uid 89); 9 Nov 2015 09:51:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 09 Nov 2015 09:51:43 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id tA99pXGm013388; Mon, 9 Nov 2015 03:51:33 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id tA99pWlJ013387; Mon, 9 Nov 2015 03:51:32 -0600 Date: Mon, 09 Nov 2015 09:51:00 -0000 From: Segher Boessenkool To: Uros Bizjak Cc: Jeff Law , Kyrill Tkachov , gcc Patches Subject: Re: [PATCH][combine][RFC] Don't transform sign and zero extends inside mults Message-ID: <20151109095132.GA13304@gate.crashing.org> References: <56376FFF.3070008@arm.com> <20151104235015.GA13203@gate.crashing.org> <563B4516.5090001@arm.com> <20151106005636.GA31412@gate.crashing.org> <563CB6DE.7070106@arm.com> <563D1824.8000607@redhat.com> <20151106220008.GA19110@gate.crashing.org> <20151108205806.GA641@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00921.txt.bz2 On Mon, Nov 09, 2015 at 08:52:13AM +0100, Uros Bizjak wrote: > On Sun, Nov 8, 2015 at 9:58 PM, Segher Boessenkool > wrote: > > On Fri, Nov 06, 2015 at 04:00:08PM -0600, Segher Boessenkool wrote: > >> This patch stops combine from generating widening muls of anything else > >> but registers (immediates, memory, ...). This probably is a reasonable > >> tradeoff for all targets, even those (if any) that have such insns. > >> > >> > >I'll let you put it through it's paces on your setup :) > >> > >> > I'll let Segher give the final yes/no on this, but it generally looks > >> > good to me. > >> > >> It looks okay to me too. Testing now, combine patches have the tendency > >> to do unforeseen things on other targets ;-) > > > > Testing shows it makes a difference only very rarely. For many targets > > it makes no difference, for a few it is a small win. For 32-bit x86 it > > creates slightly bigger code. > > > > I think it looks good, but let's wait to hear Uros' opinion. > > >From the original patch submission, it looks that this patch would > also benefit x86_32. Yes, that is what I thought too. > Regarding the above code size increase - do you perhaps have a > testcase, to see what causes the difference? I could extract some. It happens quite rarely on usual code. > It isn't necessary due to > the patch, but perhaps some loads are moved to the insn and aren't > CSE'd anymore. Segher