From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9750 invoked by alias); 9 Oct 2007 19:55:13 -0000 Received: (qmail 9742 invoked by uid 22791); 9 Oct 2007 19:55:13 -0000 X-Spam-Check-By: sourceware.org Received: from mail1.panix.com (HELO mail1.panix.com) (166.84.1.72) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 19:55:09 +0000 Received: from mailspool3.panix.com (mailspool3.panix.com [166.84.1.78]) by mail1.panix.com (Postfix) with ESMTP id 663AA29410; Tue, 9 Oct 2007 15:55:07 -0400 (EDT) Received: from [192.168.1.60] (pool-70-104-128-26.nycmny.fios.verizon.net [70.104.128.26]) by mailspool3.panix.com (Postfix) with ESMTP id 460D1169B2; Tue, 9 Oct 2007 15:55:06 -0400 (EDT) Message-ID: <470BDCA2.9020409@naturalbridge.com> Date: Tue, 09 Oct 2007 19:55:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: Eric Botcazou CC: Ian Lance Taylor , gcc-patches@gcc.gnu.org, Uros Bizjak Subject: Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638 References: <5787cf470710080514m2edaae59ma1f21c008de64800@mail.gmail.com> <200710090840.38213.ebotcazou@libertysurf.fr> <200710092139.20257.ebotcazou@libertysurf.fr> In-Reply-To: <200710092139.20257.ebotcazou@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00506.txt.bz2 Eric Botcazou wrote: >> 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] 0x55704200 __builtin_powf>) [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. > > no, it doesn't. I did not know i had to. At the time i wrote this code, i assumed that when i canonized the insn, i would just see the reference to the frame in the rtl. Eric, i am not arguing that my code in dse should stay the way that it is, i was just hoping somehow i could salvage the ability to do better things for accesses off of the frame pointer. Another issue that this brings up is the code that deletes stores into the frame pointer that die when the function returns. I am now a little worried that code may be also compromised. If i am able to see the store as being relative to the frame but there is some load whose address has been stored in a register, i am screwed. Kenny