From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30245 invoked by alias); 9 Oct 2007 19:37:18 -0000 Received: (qmail 30234 invoked by uid 22791); 9 Oct 2007 19:37:17 -0000 X-Spam-Check-By: sourceware.org Received: from mx-out.libertysurf.net (HELO mail.libertysurf.net) (213.36.80.91) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 19:37:11 +0000 Received: from [192.168.1.3] (83.156.211.230) by mail.libertysurf.net (7.3.118.8) id 470B8ACB0000D286; Tue, 9 Oct 2007 21:37:01 +0200 From: Eric Botcazou To: Ian Lance Taylor Subject: Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638 Date: Tue, 09 Oct 2007 19:37:00 -0000 User-Agent: KMail/1.7.1 Cc: gcc-patches@gcc.gnu.org, "Uros Bizjak" , zadeck@naturalbridge.com References: <5787cf470710080514m2edaae59ma1f21c008de64800@mail.gmail.com> <200710090840.38213.ebotcazou@libertysurf.fr> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710092139.20257.ebotcazou@libertysurf.fr> X-IsSubscribed: yes 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 X-SW-Source: 2007-10/txt/msg00503.txt.bz2 > It does. The problem is that CALL_INSN_FUNCTION_USAGE has a mem with > virtual-outgoing-args, but the actual store is done via a reg. The > address was copied into the reg due to -fforce-addr. No, I don't think it does. Apply Index: cselib.c =================================================================== --- cselib.c (revision 129158) +++ cselib.c (working copy) @@ -1687,7 +1687,8 @@ cselib_process_insn (rtx insn) if (CALL_P (insn)) { for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) - if (call_used_regs[i] + if ((call_used_regs[i] + && !(ACCUMULATE_OUTGOING_ARGS && i == STACK_POINTER_REGNUM)) || (REG_VALUES (i) && REG_VALUES (i)->elt && HARD_REGNO_CALL_PART_CLOBBERED (i, GET_MODE (REG_VALUES (i)->elt->val_rtx)))) and comment out the special code in dse.c for const functions that invalidates all the stores into the frame. Now compile the testcase without -fforce-addr and you'll get in cse2: (insn 1039 1038 1040 149 comunpack.f:61 (set (mem:SF (plus:SI (reg/f:SI 7 sp) (const_int 4 [0x4])) [0 S4 A32]) (reg:SF 374)) 66 {*movsf_1} (expr_list:REG_DEAD (reg:SF 374) (nil))) [...] (call_insn/u 1042 1041 1043 149 comunpack.f:61 (set (reg:SF 8 st) (call (mem:QI (symbol_ref:SI ("powf") [flags 0x41] ) [0 S1 A8]) (const_int 8 [0x8]))) 611 {*call_value_0} (nil) (expr_list:REG_DEP_TRUE (use (mem/i:SF (reg/f:SI 7 sp) [0 S4 A32])) (expr_list:REG_DEP_TRUE (use (mem/i:SF (plus:SI (reg/f:SI 7 sp) (const_int 4 [0x4])) [0 S4 A32])) (nil)))) [...] (insn 1048 1047 1049 149 comunpack.f:62 (set (mem:SF (plus:SI (reg/f:SI 7 sp) (const_int 4 [0x4])) [0 S4 A32]) (reg:SF 379)) 66 {*movsf_1} (expr_list:REG_DEAD (reg:SF 379) (nil))) And then in dse1: **scanning insn=1048 mem: (plus:SI (reg/f:SI 7 sp) (const_int 4 [0x4])) after cselib_expand address: (plus:SI (reg/f:SI 7 sp) (const_int 4 [0x4])) after canon_rtx address: (plus:SI (reg/f:SI 7 sp) (const_int 4 [0x4])) varying cselib base=2 offset = 4 processing cselib store [4..8) trying store in insn=1041 gid=-1[0..4) trying store in insn=1039 gid=-1[4..8) Locally deleting insn 1039 deferring deletion of insn with uid = 1039. mems_found = 1, cannot_delete = false [...] deleting insn with uid = 1039. and yet there is an explicit use for the store in CALL_INSN_FUNCTION_USAGE. > dse.c is not smart enough to see that the address in the > CALL_INSN_FUNCTION_USAGE is the same as the address in the register. I think that dse.c doesn't even look into CALL_INSN_FUNCTION_USAGE. -- Eric Botcazou