From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29639 invoked by alias); 10 Oct 2007 12:19:24 -0000 Received: (qmail 29629 invoked by uid 22791); 10 Oct 2007 12:19:23 -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; Wed, 10 Oct 2007 12:19:20 +0000 Received: from [192.168.1.3] (91.164.39.223) by mail.libertysurf.net (7.3.118.8) id 47026E8D001653E3; Wed, 10 Oct 2007 14:19:16 +0200 From: Eric Botcazou To: Kenneth Zadeck Subject: Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638 Date: Wed, 10 Oct 2007 12:19:00 -0000 User-Agent: KMail/1.7.1 Cc: gcc-patches@gcc.gnu.org, Ian Lance Taylor , Uros Bizjak References: <5787cf470710080514m2edaae59ma1f21c008de64800@mail.gmail.com> <470BDCA2.9020409@naturalbridge.com> <200710092357.07520.ebotcazou@libertysurf.fr> In-Reply-To: <200710092357.07520.ebotcazou@libertysurf.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710101420.43418.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/msg00551.txt.bz2 > > 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. > > This should be more or less an equivalent problem. I was wrong. Part of the problem stems from the confusion in dse.c about what "stores into the frame" are. They are defined as stores whose base is either frame_pointer_rtx or hard_frame_pointer_rtx. That's the right definition for the purpose quoted above and I think that these stores should be immune to the problem (address loaded into pseudo) because both frame_pointer_rtx and hard_frame_pointer_rtx are !rtx_varies_p, so canon_rtx will really return the canonicalized address. Now, for const functions, we are not interested in these stores into the frame as defined above, we are interested in stores based on the *stack pointer*. Quoting flow.c: /* Non-constant calls clobber memory, constant calls do not clobber memory, though they may clobber outgoing arguments on the stack. */ if (! CONST_OR_PURE_CALL_P (insn)) { free_EXPR_LIST_list (&pbi->mem_set_list); pbi->mem_set_list_len = 0; } else invalidate_mems_from_set (pbi, stack_pointer_rtx); And the solution to the canonicalization problem for those stores is already present in gcse.c: static bool store_killed_in_insn (const_rtx x, const_rtx x_regs, const_rtx insn, int after) { const_rtx reg, base, note, pat; if (!INSN_P (insn)) return false; if (CALL_P (insn)) { /* A normal or pure call might read from pattern, but a const call will not. */ if (! CONST_OR_PURE_CALL_P (insn) || pure_call_p (insn)) return true; /* But even a const call reads its parameters. Check whether the base of some of registers used in mem is stack pointer. */ for (reg = x_regs; reg; reg = XEXP (reg, 1)) { base = find_base_term (XEXP (reg, 0)); if (!base || (GET_CODE (base) == ADDRESS && GET_MODE (base) == Pmode && XEXP (base, 0) == stack_pointer_rtx)) return true; (insn 1312 1310 1313 149 comunpack.f:61 (set (mem:SF (reg/f:SI 755) [0 S4 A32]) (reg:SF 646)) 66 {*movsf_1} (expr_list:REG_DEAD (reg:SF 646) (nil))) (gdb) p debug_rtx(0x558bde40) (reg/f:SI 755) $19 = void (gdb) p debug_rtx(find_base_term(0x558bde40)) (address:SI (reg/f:SI 7 sp)) $20 = void -- Eric Botcazou