[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230802110303.1e3ceeba5a96076f723d1d08@linux-foundation.org>
Date: Wed, 2 Aug 2023 11:03:03 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Marco Elver <elver@...gle.com>
Cc: Kees Cook <keescook@...omium.org>,
Guenter Roeck <linux@...ck-us.net>,
Marc Zyngier <maz@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
Tom Rix <trix@...hat.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
Dmitry Vyukov <dvyukov@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
kasan-dev@...glegroups.com, linux-toolchains@...r.kernel.org
Subject: Re: [PATCH 1/3] Compiler attributes: Introduce the __preserve_most
function attribute
On Wed, 2 Aug 2023 17:06:37 +0200 Marco Elver <elver@...gle.com> 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.
That sounds fairly radical. And no changes are needed for assembly
code or asm statements?
I'll add "LLVM" to the patch title to make it clear that gcc isn't
affected.
Powered by blists - more mailing lists