From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113929 invoked by alias); 10 Nov 2015 19:53:16 -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 113764 invoked by uid 89); 10 Nov 2015 19:53:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 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; Tue, 10 Nov 2015 19:53:14 +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 tAAJr4bg002149; Tue, 10 Nov 2015 13:53:04 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id tAAJr48A002148; Tue, 10 Nov 2015 13:53:04 -0600 Date: Tue, 10 Nov 2015 19:53: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: <20151110195303.GB936@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> <20151109095132.GA13304@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151109095132.GA13304@gate.crashing.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01274.txt.bz2 On Mon, Nov 09, 2015 at 03:51:32AM -0600, Segher Boessenkool wrote: > > >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. I don't have a small testcase yet. What causes the degradation is that sometimes we end up with imul reg,reg instead of imul mem,reg. In the normal case we already have imul mem,reg after expand, so the patch doesn't change anything in the normal case. Even if expand didn't do it fwprop would I think. It also isn't LRA that is doing it, the MEMs in case are not on stack. Maybe as you say some CSE pass. For x86_64, which has many more registers than i386, often a peephole fires that turns a mov reg,reg ; imul mem,reg into an mov mem,reg ; imul reg,reg which makes the generated machines code identical with or without the patch (tested on a Linux build, 12MB text). The i386 size regression is 0.01% btw (comparable to the gains for other targets). Segher