Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 17 Mar 2022 14:39:34 -0700 | Subject | Re: [PATCH v5] x86: use builtins to read eflags |
| |
On Thu, Mar 17, 2022 at 2:06 PM Andrew Cooper <Andrew.Cooper3@citrix.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.
Linus
| |