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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A6EBC001E0 for ; Wed, 2 Aug 2023 16:52:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232740AbjHBQwT (ORCPT ); Wed, 2 Aug 2023 12:52:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232724AbjHBQwC (ORCPT ); Wed, 2 Aug 2023 12:52:02 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EEAD3AA8 for ; Wed, 2 Aug 2023 09:51:19 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-31751d7d96eso21957f8f.1 for ; Wed, 02 Aug 2023 09:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690995077; x=1691599877; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LrJLBG38n+Wiyfmv9S4MGg4xgt3i7BNwPWJDTs2HMj8=; b=Yr2vtAOieZy3/74CDEAGC2Gnt8sgnypV0sH1nFYDYE+Z9U73wi72vRoBj9mOPgJwjv 99wZ+YY4Rl0iV4S7hY5jTJtBu9E+Wq+0WPHsLe7dYzPVxIQ7tL3K9N9EEAXWyXptkr4R ias3QXAFYMwvc666cOayPBqLwNU+Kv7rga8bPxnBbLZRg9CrOcJ+FBK+rP2suecmhpuK 73IMHyBKaqHCKBxo5PMwGaIBZKNj+nCrhhmAYIbNw5hpKlBf+9T+TnMkonjeqbOS1kee h/worVBInk2I1mObvjC5ogsA2iH6t0VXQGFlLd+k2vwihb2JKETOekCztRRPYmPBl9O/ EQ7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690995077; x=1691599877; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LrJLBG38n+Wiyfmv9S4MGg4xgt3i7BNwPWJDTs2HMj8=; b=B+d1M1+Z+Mr3fbJfYhmyIPpaZT/8qagaquFs9wM/Fj53U4k/LPyZoM48h60yreTIS0 01qAY0blBDiL0ckDZ5skHjA8uasZigRLsBXiFUzRnrBuZPWVI9ti5VtHosRckKiBBjZ8 co6cbwhFkCvmpARwQrML6i1YdvmDHlRLWXKvSwdYJDR2evCgjxXMXFfzdpFaAt07n+hK wUBrE2GfxzkjfEG3HicVbDle0z8Y9+Go+nI9uNgC/4LXzY+42zHvDJ6REZDIgWGXNhxb syzqv95+Jze9u7Qqrpyw1qpMVE55mKICUIQvjLoHH8tHFqiNLuI6GMFkOJjCRLOwQeEH vkMQ== X-Gm-Message-State: ABy/qLa/vwkOC5+YHKRjjVE8Wx8qh3epwsNJ5dvVayhtfzHsxPn8YT3V /hF3kTs6Arfw6lM2y9s/Ud1GWNMeuAmeLLNTO4yaRw== X-Google-Smtp-Source: APBJJlEF0ih0QHv1ekEfW69+6kAWN0K+fahB0BVsKiKPMI+3V3I/aF86Y1eNpJYuOPhD4pxG0Cgwhi1Awcn8a9ebJvM= X-Received: by 2002:adf:facc:0:b0:317:49a2:1f89 with SMTP id a12-20020adffacc000000b0031749a21f89mr5196369wrs.1.1690995076610; Wed, 02 Aug 2023 09:51:16 -0700 (PDT) MIME-Version: 1.0 References: <20230802150712.3583252-1-elver@google.com> In-Reply-To: <20230802150712.3583252-1-elver@google.com> From: Marco Elver Date: Wed, 2 Aug 2023 18:50:39 +0200 Message-ID: Subject: Re: [PATCH 1/3] Compiler attributes: Introduce the __preserve_most function attribute To: elver@google.com, Andrew Morton , Kees Cook Cc: Guenter Roeck , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Miguel Ojeda , Nick Desaulniers , Nathan Chancellor , Tom Rix , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Dmitry Vyukov , Alexander Potapenko , kasan-dev@googlegroups.com, linux-toolchains@vger.kernel.org, Mark Rutland , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Wed, 2 Aug 2023 at 17:07, Marco Elver wrote: > > [1]: "On X86-64 and AArch64 targets, this attribute changes the calling > convention of a function. The preserve_most calling convention attempts > to make the code in the caller as unintrusive as possible. This > convention behaves identically to the C calling convention on how > arguments and return values are passed, but it uses a different set of > caller/callee-saved registers. This alleviates the burden of saving and > recovering a large register set before and after the call in the > caller." > > [1] https://clang.llvm.org/docs/AttributeReference.html#preserve-most > > Use of this attribute results in better code generation for calls to > very rarely called functions, such as error-reporting functions, or > rarely executed slow paths. > > Introduce the attribute to compiler_attributes.h. > > Signed-off-by: Marco Elver > --- > include/linux/compiler_attributes.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h > index 00efa35c350f..615a63ecfcf6 100644 > --- a/include/linux/compiler_attributes.h > +++ b/include/linux/compiler_attributes.h > @@ -321,6 +321,17 @@ > # define __pass_object_size(type) > #endif > > +/* > + * Optional: not supported by gcc. > + * > + * clang: https://clang.llvm.org/docs/AttributeReference.html#preserve-most > + */ > +#if __has_attribute(__preserve_most__) > +# define __preserve_most __attribute__((__preserve_most__)) > +#else > +# define __preserve_most > +#endif Mark says that there may be an issue with using this in combination with ftrace because arm64 tracing relies on AAPCS. Probably not just arm64, but also other architectures (x86?). To make this safe, I'm going to move __preserve_most to compiler_types.h and always pair it with notrace and some comments in v2.