From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3AFAC433E0 for ; Fri, 5 Mar 2021 18:24:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 64FE6650A1 for ; Fri, 5 Mar 2021 18:24:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229978AbhCESYP (ORCPT ); Fri, 5 Mar 2021 13:24:15 -0500 Received: from gate.crashing.org ([63.228.1.57]:54749 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229631AbhCESYG (ORCPT ); Fri, 5 Mar 2021 13:24:06 -0500 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 125IGTa8026099; Fri, 5 Mar 2021 12:16:29 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 125IGS7W026098; Fri, 5 Mar 2021 12:16:28 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 5 Mar 2021 12:16:28 -0600 From: Segher Boessenkool To: Christophe Leroy Cc: Nick Desaulniers , Mark Rutland , Marco Elver , Catalin Marinas , linuxppc-dev , LKML , kasan-dev , Mark Brown , Paul Mackerras , linux-toolchains@vger.kernel.org, Will Deacon , Linux ARM Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210305181628.GW29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> <20210304165923.GA60457@C02TD0UTHF1T.local> <20210304192447.GT29191@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Mar 05, 2021 at 07:38:25AM +0100, Christophe Leroy wrote: > Le 04/03/2021 à 20:24, Segher Boessenkool a écrit : > https://github.com/linuxppc/linux/commit/a9a3ed1eff36 > > > > >That is much heavier than needed (an mb()). You can just put an empty > >inline asm after a call before a return, and that call cannot be > >optimised to a sibling call: (the end of a function is an implicit > >return:) > In the commit mentionned at the top, it is said: > > The next attempt to prevent compilers from tail-call optimizing > the last function call cpu_startup_entry(), ... , was to add an empty > asm(""). > > This current solution was short and sweet, and reportedly, is supported > by both compilers but we didn't get very far this time: future (LTO?) > optimization passes could potentially eliminate this, This is simply not true. A volatile inline asm (like this is, all asm without outputs are) is always run on the reel machine exactly like on the abstract machine. LTO can not eliminate it, not more than any other optimisation can. The compiler makes no assumption about the constents of the template of an asm, empty or not. If you are really scared the compiler violates the rules of GCC inline asm and thinks it knows what "" means, you can write asm(";#"); (that is a comment on all supported archs). > which leads us > to the third attempt: having an actual memory barrier there which the > compiler cannot ignore or move around etc. Why would it not be allowed to delete this, and delete some other asm? And the compiler *can* move around asm like this. But the point is, it has to stay in order with other side effects, so there cannot be a sibling call here, the call has to remain: any call contains a sequence point, so side effects cannot be reordered over it, so the call (being before the asm) cannot be transformed to a tail call. Segher From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1992CC433E6 for ; Fri, 5 Mar 2021 18:21:19 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4D73564DF4 for ; Fri, 5 Mar 2021 18:21:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D73564DF4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Dsbf44x9rz3dJX for ; Sat, 6 Mar 2021 05:21:16 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=permerror (SPF Permanent Error: Unknown mechanism found: ip:192.40.192.88/32) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lists.ozlabs.org (Postfix) with ESMTP id 4Dsbdj2TLXz3cmM for ; Sat, 6 Mar 2021 05:20:56 +1100 (AEDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 125IGTa8026099; Fri, 5 Mar 2021 12:16:29 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 125IGS7W026098; Fri, 5 Mar 2021 12:16:28 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 5 Mar 2021 12:16:28 -0600 From: Segher Boessenkool To: Christophe Leroy Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210305181628.GW29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> <20210304165923.GA60457@C02TD0UTHF1T.local> <20210304192447.GT29191@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Marco Elver , Will Deacon , Catalin Marinas , Nick Desaulniers , LKML , kasan-dev , Mark Brown , Paul Mackerras , linux-toolchains@vger.kernel.org, linuxppc-dev , Linux ARM Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Mar 05, 2021 at 07:38:25AM +0100, Christophe Leroy wrote: > Le 04/03/2021 à 20:24, Segher Boessenkool a écrit : > https://github.com/linuxppc/linux/commit/a9a3ed1eff36 > > > > >That is much heavier than needed (an mb()). You can just put an empty > >inline asm after a call before a return, and that call cannot be > >optimised to a sibling call: (the end of a function is an implicit > >return:) > In the commit mentionned at the top, it is said: > > The next attempt to prevent compilers from tail-call optimizing > the last function call cpu_startup_entry(), ... , was to add an empty > asm(""). > > This current solution was short and sweet, and reportedly, is supported > by both compilers but we didn't get very far this time: future (LTO?) > optimization passes could potentially eliminate this, This is simply not true. A volatile inline asm (like this is, all asm without outputs are) is always run on the reel machine exactly like on the abstract machine. LTO can not eliminate it, not more than any other optimisation can. The compiler makes no assumption about the constents of the template of an asm, empty or not. If you are really scared the compiler violates the rules of GCC inline asm and thinks it knows what "" means, you can write asm(";#"); (that is a comment on all supported archs). > which leads us > to the third attempt: having an actual memory barrier there which the > compiler cannot ignore or move around etc. Why would it not be allowed to delete this, and delete some other asm? And the compiler *can* move around asm like this. But the point is, it has to stay in order with other side effects, so there cannot be a sibling call here, the call has to remain: any call contains a sequence point, so side effects cannot be reordered over it, so the call (being before the asm) cannot be transformed to a tail call. Segher From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC40CC433E0 for ; Fri, 5 Mar 2021 18:21:18 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 73B80650A3 for ; Fri, 5 Mar 2021 18:21:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 73B80650A3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Mime-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tmAhuojDkEN8g+guURxUqef19P4FAQINRwiNN8ZYkHE=; b=DCp1OKQGgYA925CnHvxkdPsIu 8/oSCTu7c9POL3NQnCti2XZYpN0SZ9Qr7H2VkbMTcee40+0wrNxeR2mJM1tKPkoID1jtwUF7oooxb K5Cii0NRI9UMB4sssrqfLavScJuPwa8ZpZie+rPqmmavKjwcKsR9gtzXl0UqszdHguO6WJ5+vviv0 neoGYMq/QjeZEfKBMl03ZjO827kr5trKaDZYQ81hXSfhBE3r1b2edZ6Pbf5vsSl/dPnbo0H9DuR3c oRlP9iJUcpu7DUg1YBfU/zd6GaQwfA5YhitUGsNngk8pQKUVZuol2cvQIcBZiNH/ijnVvIm3N7LRG jyrRikupQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lIF3L-00Fw5C-Is; Fri, 05 Mar 2021 18:19:55 +0000 Received: from gate.crashing.org ([63.228.1.57]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lIF3G-00Fw3V-28 for linux-arm-kernel@lists.infradead.org; Fri, 05 Mar 2021 18:19:53 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 125IGTa8026099; Fri, 5 Mar 2021 12:16:29 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 125IGS7W026098; Fri, 5 Mar 2021 12:16:28 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 5 Mar 2021 12:16:28 -0600 From: Segher Boessenkool To: Christophe Leroy Cc: Nick Desaulniers , Mark Rutland , Marco Elver , Catalin Marinas , linuxppc-dev , LKML , kasan-dev , Mark Brown , Paul Mackerras , linux-toolchains@vger.kernel.org, Will Deacon , Linux ARM Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210305181628.GW29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> <20210304165923.GA60457@C02TD0UTHF1T.local> <20210304192447.GT29191@gate.crashing.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210305_181950_886449_69DD3AB5 X-CRM114-Status: GOOD ( 19.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Mar 05, 2021 at 07:38:25AM +0100, Christophe Leroy wrote: > Le 04/03/2021 =E0 20:24, Segher Boessenkool a =E9crit=A0: > https://github.com/linuxppc/linux/commit/a9a3ed1eff36 > = > > > >That is much heavier than needed (an mb()). You can just put an empty > >inline asm after a call before a return, and that call cannot be > >optimised to a sibling call: (the end of a function is an implicit > >return:) > In the commit mentionned at the top, it is said: > = > The next attempt to prevent compilers from tail-call optimizing > the last function call cpu_startup_entry(), ... , was to add an empty = > asm(""). > = > This current solution was short and sweet, and reportedly, is supported > by both compilers but we didn't get very far this time: future (LTO?) > optimization passes could potentially eliminate this, This is simply not true. A volatile inline asm (like this is, all asm without outputs are) is always run on the reel machine exactly like on the abstract machine. LTO can not eliminate it, not more than any other optimisation can. The compiler makes no assumption about the constents of the template of an asm, empty or not. If you are really scared the compiler violates the rules of GCC inline asm and thinks it knows what "" means, you can write asm(";#"); (that is a comment on all supported archs). > which leads us > to the third attempt: having an actual memory barrier there which the > compiler cannot ignore or move around etc. Why would it not be allowed to delete this, and delete some other asm? And the compiler *can* move around asm like this. But the point is, it has to stay in order with other side effects, so there cannot be a sibling call here, the call has to remain: any call contains a sequence point, so side effects cannot be reordered over it, so the call (being before the asm) cannot be transformed to a tail call. Segher _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel