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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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 E1C91C4743D for ; Sun, 6 Jun 2021 23:46:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BAD106142A for ; Sun, 6 Jun 2021 23:46:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230128AbhFFXsC (ORCPT ); Sun, 6 Jun 2021 19:48:02 -0400 Received: from mail-lj1-f170.google.com ([209.85.208.170]:34683 "EHLO mail-lj1-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229885AbhFFXsB (ORCPT ); Sun, 6 Jun 2021 19:48:01 -0400 Received: by mail-lj1-f170.google.com with SMTP id bn21so19646429ljb.1 for ; Sun, 06 Jun 2021 16:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Uu/Sy+/+5gdn1LkuXnr8FX4KpSViz81yPU6cQOIlizA=; b=HSOFWCYaI4JplGo9PNU8Bbt0H04vfi4A8D71uHnmXedCnIPRXbvEu7QZL5Kfsp2DdB GidNETequ5xm/f7hshUSXwVIbVerCUNNb+kZ4sNwu+M9BpRkS7WFpDAntvD1YfeqZFSd zxowt78Mgw/V1HxA4xvQfdXdxrScPi3XPIblk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Uu/Sy+/+5gdn1LkuXnr8FX4KpSViz81yPU6cQOIlizA=; b=NSw5tLWt9rUO3o4qKiQtOKAAaq27oH0nqFMV0gLDBqTL5CrQpLJWrwEtBx4GvXSTfS 0OUNiAy8VuERe2ZdRjzpbkl/MN8wuFk504lv7lUuSLFDhwZ0EuxVqWw1Uv1pcrCCmrNp MK7PuNrSSkVaj+ZgNoJPD84tC0nmKrd5QLprRlV4EuNZ1hWN2/2NUSpwqLE7ug6YWaeF wAvb53OuzT4nr6RuI3FUUq8l8z0EMFB4qVucd8UvvYXyvXbMaGVFJLW3wC26BH3iSruf phM5sVY5uupEjRbYO11JdXgO7F06idSK3HAKfzxIOtFsJjx/1mdQ2eCBuJQv57jWZZ9e FFMA== X-Gm-Message-State: AOAM533KgTOx0ziwcmxUJVm6Rbo6b/LdGaB4B+mpYmocWKx+BUzIZaxp MgnIJLGjvONwbpAq0J6TO1nH/g== X-Google-Smtp-Source: ABdhPJw25WTHEUwJF3hh14WICkof9eE2YFmWHbJ0kkQobeinrEJjM65xyfo24FS/tSzfPJJS79gDYQ== X-Received: by 2002:a2e:8009:: with SMTP id j9mr12870582ljg.172.1623023101380; Sun, 06 Jun 2021 16:45:01 -0700 (PDT) Received: from [172.17.20.50] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id x3sm448542ljd.12.2021.06.06.16.45.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 16:45:00 -0700 (PDT) Subject: Re: [RFC] LKMM: Add volatile_if() From: Rasmus Villemoes To: Linus Torvalds , Alexander Monakov Cc: Jakub Jelinek , Alan Stern , Segher Boessenkool , "Paul E. McKenney" , Peter Zijlstra , Will Deacon , 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 References: <20210604205600.GB4397@paulmck-ThinkPad-P17-Gen-1> <20210604214010.GD4397@paulmck-ThinkPad-P17-Gen-1> <20210605145739.GB1712909@rowland.harvard.edu> <20210606001418.GH4397@paulmck-ThinkPad-P17-Gen-1> <20210606012903.GA1723421@rowland.harvard.edu> <20210606185922.GF7746@tucnak> Message-ID: <193ca8cf-cf2c-9372-c0ab-16714ec37f57@rasmusvillemoes.dk> Date: Mon, 7 Jun 2021 01:44:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/06/2021 01.39, Rasmus Villemoes wrote: > memory". Replacing with a call to an extern function marked pure does > indeed cause gcc to cache the value of y*z, so in theory this should be > possible, if one could convince gcc to "trust me, this really is a pure > function". Don't know why I didn't think to check before sending, but FWIW clang doesn't need convincing, it already takes the __pure at face value and caches y*z. Rasmus