From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26850 invoked by alias); 4 Feb 2013 18:20:43 -0000 Received: (qmail 26741 invoked by uid 48); 4 Feb 2013 18:20:17 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom. Date: Mon, 04 Feb 2013 18:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg00305.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151 --- Comment #9 from Jakub Jelinek 2013-02-04 18:20:09 UTC --- (In reply to comment #8) > (In reply to comment #7) > > Created attachment 29350 [details] > > gcc48-pr56151.patch > > > > Untested patch for the peephole mentioned in previous comment. > > I don't think a new set of peepholes is an appropriate solution for > this problem, because the same issue can show up on any CISC-like > target. Before my patch, the code was good after 'expand' by optabs, > perhaps the code your peephole tries to create, can be emitted from > there instead. And perhaps, longer term, combine should be changed > to try the more profitable combination before the one it performs now. My patch wasn't meant as a replacement of the optabs.c change, but as a complement. As the sequence into which it attempts to peephole is shorter and supposedly faster on some CPUs at least, if such an insn sequence appears in the IL anywhere during RTL optimizations, it can optimize it.