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 E2E96385702C for ; Mon, 5 Jul 2021 23:31:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2E96385702C 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 165NU9Gq021534; Mon, 5 Jul 2021 18:30:09 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 165NU9m4021533; Mon, 5 Jul 2021 18:30:09 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 5 Jul 2021 18:30:08 -0500 From: Segher Boessenkool To: liuhongt Cc: gcc-patches@gcc.gnu.org, jakub@redhat.com, richard.sandiford@arm.com, ubizjak@gmail.com Subject: Re: [PATCH 1/2] CALL_INSN may not be a real function call. Message-ID: <20210705233008.GJ1583@gate.crashing.org> References: <20210603065408.47912-1-hongtao.liu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210603065408.47912-1-hongtao.liu@intel.com> 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: Mon, 05 Jul 2021 23:31:16 -0000 Hi! 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 fine with me, but as it is, no one can know when to use this. What does "its own function stack" mean in the description here? You can only put FAKE_CALL on functions that do not have a stack frame? But that is never true on x86, so that cannot be it, unless there isn't a call instruction at all? But then, why use an RTL call insn for this? Other targets simply do not use an RTL "call" when they want to hide such an instruction, why can't you do that here, wouldn't that work much better? There are many more insns that you may want to hide. The traditional solution is to use unspecs, which very directly hides all details. Segher