From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2960 invoked by alias); 3 Feb 2011 14:32:19 -0000 Received: (qmail 2951 invoked by uid 22791); 3 Feb 2011 14:32:18 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Feb 2011 14:32:14 +0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/47521] Unnecessary usage of edx register 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, ra X-Bugzilla-Severity: minor X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.4.6 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 Date: Thu, 03 Feb 2011 14:32:00 -0000 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: 2011-02/txt/msg00506.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521 --- Comment #6 from Jeffrey A. Law 2011-02-03 14:32:03 UTC --- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/03/11 07:16, tony.poppleton at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521 > > --- Comment #5 from Tony Poppleton 2011-02-03 14:16:01 UTC --- > As a quick test, would this be fixed by re-ordering the register file to move > eax above edx? It's like flipping a coin. Sometimes its heads, sometimes its tails, tailoring the compiler around the fact that for this code we got tails isn't an approach we generally take. There is no sound reason to change the ordering of the registers. > > If so, then another possible fix to this would be to effectively re-run the RA > pass multiple times, each time using a different register file, and then select > the one that produces the "best" code and discard the other RA attempts. I don't think we're likely to take this approach. As I mentioned earlier, using %edx is a complete and total red herring; ignore it. The real issue here is there's an unnecessary reg-reg copy. The unnecessary copy can be attributed to many factors (coalescing early, combine's inability to deal with hard regs well, reload's inability to handle hard regs well in certain circumstances, IRA not realizing the ranges of "a" can profitably be split, etc). Those are the avenues I would suggest someone wanting to fix this bug pursue. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNSrxYAAoJEBRtltQi2kC7QKgH/05w+yEifZXhs+H/ueGrUk7f Z+H60AE8iGt10Z2w90bQEWAABLk8yeucZi/4g3tpwcqEwbmWn3FSyRYKlebdtPyn hTuq1ysIbjiN6lSfECvBUApSiATOJkHUi9izvriiOye5Zhn0LUKVBRtFWBLwnE0E MejL8vqkaMowCjC0+OJxuEyYNNBZj/YleOVwpjIH3kRxyWOv5p0UA2omah1bvDGs a4a7bCemRB04LByZL30JyXx/wpa8JHcEsLSlM0Him/JiRx6VNMj37uXVQVVn4CfX JP0CzZq9+7tzeaiT36cfdWKX9kPTRObPPVbAuYhkJc4jgoxsPxlxB6REh5Hkx34= =YmpV -----END PGP SIGNATURE-----