Message-ID: <83b33afc-8502-0065-60bc-3a91528632d8@kernel.org>
Date:   Fri, 18 Mar 2022 10:59:28 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Cooper <Andrew.Cooper3@...rix.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        "H. Peter Anvin" <hpa@...or.com>, Bill Wendling <morbo@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Juergen Gross <jgross@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-toolchains <linux-toolchains@...r.kernel.org>
Subject: Re: [PATCH v5] x86: use builtins to read eflags

On 3/17/22 14:39, Linus Torvalds wrote:
> On Thu, Mar 17, 2022 at 2:06 PM Andrew Cooper <Andrew.Cooper3@...rix.com> wrote:
>>
>> I was idly playing with this builtin in response to the thread, and
>> found that GCC has a far more serious bug than Clang had.
> 
> Heh. Yeah, that's bad.
> 
> But it kind of fits my argument: compiler intrinsics aren't
> necessarily such a wonderful thing. They hardly get any testing at all
> unless they are some very very core thing.
> 
> I will personally *always* prefer some generic "escape clause" over a
> compiler that thinks it knows better.
> 
> I think compiler people should see inline asm as a really *good*
> thing, because it allows people to have that "I'm going to do
> something that nobody normal does, look away now" kind of escape
> clause, letting the compiler concentrate on the things it does best.
> 
> Yes, I realize inline asm isn't something compiler people love. And
> yes, I realize that it might not give optimal code.
> 
> But think of it a bit like casts - it adds complexity to the language,
> and it might make some optimizations harder or even impossible - but
> it makes the language much more powerful and allows you to do things
> that you simply couldn't do without it.
> 
> There's a reason people use C instead of Pascal or FORTRAN. Those
> casts, and that pointer arithmetic - the bane of many optimizations -
> are really really good things.
> 
> Intrinsics should generally be shunned, not seen as a "this is an
> alternative to inline asm". They should only exist for situations
> where you can show "look, I can do so much better", and have a
> test-suite for it and a real-life case where it gives you a clear and
> undeniable uplift on a meaningful load.
> 
> (And here I separate 'intrinsic' and generic compiler builtins. I love
> the builtins that allow me to tell the compiler something, or the
> compiler to tell me something about the code: __builtin_unreachable()
> and __builtin_constant_p() are both wonderful examples of those kinds
> of things)
> 
> But an intrinsic for some odd target-specific thing that can't even be
> portably generalized? Give me inline asm any day.
> 
> We can do things with inline asms that the compiler can't even _dream_
> of, like the whole instruction rewriting thing we use.
> 
> I'd much rather have a powerful generic concept (eg "asm goto" is
> lovely) than a specialized intrinsic that does only one thing, and
> doesn't even do it well because it's untested and badly defined.
> 

I generally agree.  In this particular case, though, I will keep using 
the builtin in tools/testing/selftests/x86/helpers.h unless we actually 
hit breakage.  This is because this is *user* code, it is compiled with 
the redzone enabled, and the asm code to do the right thing when the 
redzone is enabled is too hairy for me to want to deal with it.  The 
builtins have their share of problems, but they do seem to work in this 
context.

This isn't at all an argument that we should do the same thing in actual 
kernel code.

Powered by blists - more mailing lists