From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12334 invoked by alias); 3 Jan 2015 20:58:48 -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 12323 invoked by uid 89); 3 Jan 2015 20:58:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: BLU004-OMC3S37.hotmail.com Received: from blu004-omc3s37.hotmail.com (HELO BLU004-OMC3S37.hotmail.com) (65.55.116.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Sat, 03 Jan 2015 20:58:46 +0000 Received: from BLU436-SMTP216 ([65.55.116.73]) by BLU004-OMC3S37.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sat, 3 Jan 2015 12:58:43 -0800 X-TMN: [CDn0orcZZZ08mLkH6FwfcspVzWxgMaDi] Message-ID: Subject: Re: PATCH: [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c MIME-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset="us-ascii" From: John David Anglin In-Reply-To: Date: Sat, 03 Jan 2015 20:58:00 -0000 CC: GCC Patches , Jeffrey Law Content-Transfer-Encoding: quoted-printable References: <20141231141317.GA575@gmail.com> <20150103173548.GA22839@hiauly1.hia.nrc.ca> To: "H.J. Lu" X-SW-Source: 2015-01/txt/msg00067.txt.bz2 On 2015-01-03, at 3:18 PM, H.J. Lu wrote: > 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: >>=20 >>> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin >>> wrote: >>>> On Wed, 31 Dec 2014, H.J. Lu wrote: >>>>=20 >>>>> - /* 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; >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> That will a new optimization. I am trying to restore the old behavior = on >>> x86 with minimum impact in stage 3. >>=20 >>=20 >> 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: >>=20 >> 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); >>=20 >=20 > Revision 219037 has >=20 > 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) >=20 > insn_info->cannot_delete =3D true; >=20 > + /* Arguments for a sibling call that are pushed to memory are pass= ed > + 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. >=20 > My patch changes it to >=20 > 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) >=20 > insn_info->cannot_delete =3D true; >=20 > + 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. >=20 > On x86, it is the same as before revision 219037 since > targetm.sibcall_wild_read_p always returns false on x86. Understood. The point is the subsequent code for const functions is based = on assumptions that are not generally true for sibcalls: /* This field is only used for the processing of const functions. These functions cannot read memory, but they can read the stack because that is where they may get their parms. We need to be this conservative because, like the store motion pass, we don't consider CALL_INSN_FUNCTION_USAGE when processing call insns. Moreover, we need to distinguish two cases: 1. Before reload (register elimination), the stores related to outgoing arguments are stack pointer based and thus deemed of non-constant base in this pass. This requires special handling but also means that the frame pointer based stores need not be killed upon encountering a const function call. 2. After reload, the stores related to outgoing arguments can be either stack pointer or hard frame pointer based. This means that we have no other choice than also killing all the frame pointer based stores upon encountering a const function call. This field is set after reload for const function calls. Having this set is less severe than a wild read, it just means that all the frame related stores are killed rather than all the stores. */ bool frame_read; For example, the stores related to sibcall arguments are not in general sta= ck pointer based. This suggests to me that we don't have to always kill stack pointer based stores= in the const sibcall case and they can be optimized. For me, keeping the sibcall handling separate from normal calls is easier t= o understand and potentially provides a means to optimize stack pointer based stores. Are y= ou sure that the prior behaviour was always correct on x86 (e.g., more than 6 arguments)? Dave -- John David Anglin dave.anglin@bell.net