From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21440 invoked by alias); 3 Jan 2015 20:18:43 -0000 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 Received: (qmail 21430 invoked by uid 89); 3 Jan 2015 20:18:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 03 Jan 2015 20:18:41 +0000 Received: by mail-ob0-f174.google.com with SMTP id nt9so62571407obb.5 for ; Sat, 03 Jan 2015 12:18:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.102.159 with SMTP id m31mr46087111oik.67.1420316319544; Sat, 03 Jan 2015 12:18:39 -0800 (PST) Received: by 10.76.185.7 with HTTP; Sat, 3 Jan 2015 12:18:39 -0800 (PST) In-Reply-To: References: <20141231141317.GA575@gmail.com> <20150103173548.GA22839@hiauly1.hia.nrc.ca> Date: Sat, 03 Jan 2015 20:18:00 -0000 Message-ID: Subject: Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c From: "H.J. Lu" To: John David Anglin Cc: GCC Patches , Jeffrey Law Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00065.txt.bz2 On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin wrote: > On 2015-01-03, at 2:48 PM, H.J. Lu wrote: > >> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin >> wrote: >>> On Wed, 31 Dec 2014, H.J. Lu wrote: >>> >>>> - /* Arguments for a sibling call that are pushed to memory are passed >>>> - using the incoming argument pointer of the current function. These >>>> - may or may not be frame related depending on the target. Since >>>> - argument pointer related stores are not currently tracked, we treat >>>> - a sibling call as though it does a wild read. */ >>>> - if (SIBLING_CALL_P (insn)) >>>> + if (targetm.sibcall_wild_read_p (insn)) >>>> { >>>> add_wild_read (bb_info); >>>> return; >>> >>> Instead of falling through to code designed to handle normal calls, it >>> would be better to treat them separately. Potentially, there are other >>> optimizations that may be applicable. If a sibcall doesn't read from >>> the frame, add_non_frame_wild_read() can be called. This would restore >>> the x86 optimization. >>> >> >> That will a new optimization. I am trying to restore the old behavior on >> x86 with minimum impact in stage 3. > > > Not really. In gcc.dg/pr44194-1.c, the sibcall was not a const function and this case > was covered by this hunk of code: > > else > /* Every other call, including pure functions, may read any memory > that is not relative to the frame. */ > add_non_frame_wild_read (bb_info); > Revision 219037 has diff --git a/gcc/dse.c b/gcc/dse.c index 2555bd1..3a7f31c 100644 --- a/gcc/dse.c +++ b/gcc/dse.c @@ -2483,6 +2483,17 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn) insn_info->cannot_delete = true; + /* Arguments for a sibling call that are pushed to memory are passed + using the incoming argument pointer of the current function. These + may or may not be frame related depending on the target. Since + argument pointer related stores are not currently tracked, we treat + a sibling call as though it does a wild read. */ + if (SIBLING_CALL_P (insn)) + { + add_wild_read (bb_info); + return; + } + /* Const functions cannot do anything bad i.e. read memory, however, they can read their parameters which may have been pushed onto the stack. My patch changes it to diff --git a/gcc/dse.c b/gcc/dse.c index 2555bd1..c0e1a0c 100644 --- a/gcc/dse.c +++ b/gcc/dse.c @@ -2483,6 +2483,12 @@ scan_insn (bb_info_t bb_info, rtx_insn *insn) insn_info->cannot_delete = true; + if (targetm.sibcall_wild_read_p (insn)) + { + add_wild_read (bb_info); + return; + } + /* Const functions cannot do anything bad i.e. read memory, however, they can read their parameters which may have been pushed onto the stack. On x86, it is the same as before revision 219037 since targetm.sibcall_wild_read_p always returns false on x86. -- H.J.