From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30886 invoked by alias); 10 Jul 2003 20:09:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30879 invoked by uid 48); 10 Jul 2003 20:09:16 -0000 Date: Thu, 10 Jul 2003 20:09:00 -0000 Message-ID: <20030710200916.30878.qmail@sources.redhat.com> From: "steven at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20020506130600.6585.bruno@clisp.org> References: <20020506130600.6585.bruno@clisp.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug optimization/6585] Reduntant store/load instruction pairs on ix86 X-Bugzilla-Reason: CC X-SW-Source: 2003-07/txt/msg01120.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585 steven at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|useless memory store |Reduntant store/load |instructions on x86 |instruction pairs on ix86 ------- Additional Comments From steven at gcc dot gnu dot org 2003-07-10 20:09 ------- After looking into this a bit further and after consulting with Zdenek, I believe we should blaim this bug on something in the register allocator. But then again the same problem exists with -fnew-ra, so maybe it's something in the i386 backend (register sets???). Maybe someone can try on a different 32bits target and see if the problem exists there as well. Anyway, before register allocation it looks reasonable, but after global reg alloc we get this insns: (insn 39 18 24 0 (set (mem:SI (plus:SI (reg/f:SI 7 esp) (const_int 4 [0x4])) [3 S4 A8]) (reg:SI 2 ecx)) 39 {*movsi_1_nointernunit} (nil) (nil)) (note:HI 24 39 27 0 NOTE_INSN_FUNCTION_END) (insn:HI 27 24 30 0 (set (reg/i:DI 0 rax [ ]) (mem:DI (reg/f:SI 7 esp) [3 S8 A8])) 60 {*movdi_2} (insn_list 18 (nil)) (nil)) %ecx is put in the stack and subsequently loaded into %edx when the result insn is expanded. (After some black magic apparently %ecx is replaced with %ebx post reload...)