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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 7130CC4743D for ; Fri, 4 Jun 2021 18:30:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C6FA613FA for ; Fri, 4 Jun 2021 18:30:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229982AbhFDSby (ORCPT ); Fri, 4 Jun 2021 14:31:54 -0400 Received: from gate.crashing.org ([63.228.1.57]:39809 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229769AbhFDSby (ORCPT ); Fri, 4 Jun 2021 14:31:54 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 154IPkRL003330; Fri, 4 Jun 2021 13:25:46 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 154IPjK0003329; Fri, 4 Jun 2021 13:25:45 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 4 Jun 2021 13:25:44 -0500 From: Segher Boessenkool To: Linus Torvalds Cc: Peter Zijlstra , Will Deacon , "Paul E. McKenney" , Alan Stern , Andrea Parri , Boqun Feng , Nick Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Linux Kernel Mailing List , linux-toolchains@vger.kernel.org, linux-arch Subject: Re: [RFC] LKMM: Add volatile_if() Message-ID: <20210604182544.GK18427@gate.crashing.org> References: <20210604172407.GJ18427@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 Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org Hi! On Fri, Jun 04, 2021 at 10:38:43AM -0700, Linus Torvalds wrote: > On Fri, Jun 4, 2021 at 10:27 AM Segher Boessenkool > wrote: > > > Of course, we might want to make sure that the compiler doesn't go > > > "oh, empty asm, I can ignore it", > > > > It isn't allowed to do that. GCC has this arguable misfeature where it > > doesn't show empty asm in the assembler output, but that has no bearing > > on anything but how human-readable the output is. > > That sounds about right, but we have had people talking about the > compiler looking inside the asm string before. > > So it worries me that some compiler person might at some point go all > breathy-voice on us and say "I am altering the deal. Pray I don't > alter it any further". GCC will never do that. And neither will any other compiler that claims to implement the GCC asm extensions, if they are true to their word. GCC *does* look inside the assembler template to estimate what code size this asm will generate, and it tries to be pessimistic about its estimate so that this will always work, but it always is possible to mislead the compiler here, precisely because it does not actually pretend it understands assembler code (think .irp or anything with assembler macros for example). In very rare cases this leads to (assembler) errors ("jump target out of range", that kind of thing). The most effective workaround is to write less silly code ;-) And of course this is documented, see > Side note: when grepping for what "barrier()" does on different > architectures and different compilers, I note that yes, it really is > just an empty asm volatile with a "memory" barrier. That should in all > way sbe sufficient. > > BUT. > > There's this really odd comment in that talks > about some "ECC" compiler: > > /* Intel ECC compiler doesn't support gcc specific asm stmts. > * It uses intrinsics to do the equivalent things. > */ > > and it defines it as "__memory_barrier()". This seems to be an ia64 thing, but: "ecc" apparently was "icc" but for Itanium. It ceased to exist some time in the 2.4 era apparently. It was still used in 2003. Searching for "ecpc" (the C++ compiler driver) will find a bit more. > - I cannot get google to find me any documentation on such an intrinsic > > - it seems to be bogus anyway, since we have "asm volatile" usage in > at least arch/ia64/mm/tlb.c > > So I do note that "barrier()" has an odd definition in one odd ia64 > case, and I can't find the semantics for it. > > Admittedly I also cannot find it in myself to care. Yeah, I love code archaeology, but I have work to do as well :-) > I don't think that > "Intel ECC" compiler case actually exists, and even if it does I don't > think itanium is relevant any more. But it was an odd detail on what > "barrier()" actually might mean to the compiler. :-) Segher