From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 7EC0C395B818 for ; Wed, 7 Jul 2021 14:53:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7EC0C395B818 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 167EqdVc008702; Wed, 7 Jul 2021 09:52:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 167Eqc9X008701; Wed, 7 Jul 2021 09:52:38 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 7 Jul 2021 09:52:38 -0500 From: Segher Boessenkool To: Richard Biener Cc: Hongtao Liu , Jakub Jelinek , Richard Sandiford , liuhongt , GCC Patches Subject: Re: [PATCH 1/2] CALL_INSN may not be a real function call. Message-ID: <20210707145238.GL1583@gate.crashing.org> References: <20210603065408.47912-1-hongtao.liu@intel.com> <20210705233008.GJ1583@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 14:53:44 -0000 Hi! On Wed, Jul 07, 2021 at 10:15:08AM +0200, Richard Biener wrote: > On Wed, Jul 7, 2021 at 4:40 AM Hongtao Liu via Gcc-patches > wrote: > > On Tue, Jul 6, 2021 at 9:37 AM Hongtao Liu wrote: > > > On Tue, Jul 6, 2021 at 7:31 AM Segher Boessenkool > > > wrote: > > > > I ran into this in shrink-wrap.c today. > > > > > > > > On Thu, Jun 03, 2021 at 02:54:07PM +0800, liuhongt via Gcc-patches wrote: > > > > > Use "used" flag for CALL_INSN to indicate it's a fake call. If it's a > > > > > fake call, it won't have its own function stack. > > > > > > > > Could you document somewhere what a "fake call" *is*? Including what > > > > that means to RTL, how this is expected to be used, etc.? In rtl.h is > > > fake call is used for TARGET_INSN_CALLEE_ABI, i'll add comments for > > > #define FAKE_CALL_P(RTX) in rtl.h > > > > > > Here's the patch I'm going to check in. Which doesn't do any of the things I asked for :-( It doesn't say what a "fake call" is, it doesn't say what its semantics are, it doesn't say how it is exected to be used. So, a "FAKE_CALL" is very much a *real* call, on the RTL level, which is where we are here. But you want it to be treated differently because it will eventually be replaced by different insns. This causes all kinds of unrelated code to need confusing changes, made much worse because the name "FAKE_CALL" is the opposite of what it does. As long as your description of it only says how it is (ab)used in one case, I will call it a hack, and a gross hack at that. > > --- a/gcc/rtl.h > > +++ b/gcc/rtl.h > > @@ -840,7 +840,13 @@ struct GTY(()) rtvec_def { > > #define CALL_P(X) (GET_CODE (X) == CALL_INSN) > > > > /* 1 if RTX is a call_insn for a fake call. > > - CALL_INSN use "used" flag to indicate it's a fake call. */ > > + CALL_INSN use "used" flag to indicate it's a fake call. > > + Used by the x86 vzeroupper instruction, > > + in order to solve the problem of partial clobber registers, > > + vzeroupper is defined as a call_insn with a special callee_abi, > > + but it is not a real call and therefore has no function stack > > + of its own. So because of this one thing (you need to insert partial clobbers) you force all kinds of unrelated code to have changes, namely, code thatt needs to do something with calls, but now you do not want to have that doone on some calls because you promise that call will disappear eventually, and it cannot cause any problems in the mean time? I am not convinced. This is not design, this is a terrible hack, this is the opposite direction we should go in. > that doesn't set up a stack frame is fake as well? Maybe > > "CALL_INSN use "used" flag to indicate the instruction > does not transfer control." > > thus that this call is not affecting regular control flow? (it might > eventually still trap and thus cause non-call EH?) How it is used in shrink-wrap requires it to not have a stack frame (in the compiler sense). > Not sure if "no function stack of its own" is a good constraint, > vzeroupper does not perform any call or jump. Yeah. This stuff needs a rethink. What is wrong with just using an unspec and clobbers? Segher