[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFULd4bwsZENN5eVLXDDizt6+EcdwgnFBaS4b7YjjqzR-Rmjjw@mail.gmail.com>
Date: Fri, 14 Mar 2025 14:22:45 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/asm: Use asm_inline() instead of asm() in __untagged_addr()
On Fri, Mar 14, 2025 at 12:25 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Fri, Mar 14, 2025 at 10:30:55AM +0100, Uros Bizjak wrote:
> > Use asm_inline() to instruct the compiler that the size of asm()
> > is the minimum size of one instruction, ignoring how many instructions
> > the compiler thinks it is. ALTERNATIVE macro that expands to several
> > pseudo directives causes instruction length estimate to count
> > more than 20 instructions.
> >
> > bloat-o-meter reports minimal code size increase
>
> If you see an increase and *no* *other* *palpable* improvement, you don't send
> it. It is that simple.
Do you see the removed functions? These are now fully inlined and
optimized in their inlined places. The program does not have to set up
a function call, invoke call/ret insn and create a frame in the called
function. The well tuned compiler heuristics make trade offs between
performance and code growth and it chose it that way. The heuristics
are as good as the data the programmer provides, and choking the
compiler with incorrect data, as provided by asm() interface,
certainly does no good. The asm() code in the patch declares *one*
instruction, not 23. Please count it.
Code size is not the right metric with -O2. It is that simple.
BR,
Uros.
Powered by blists - more mailing lists