Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH] x86: use builtins to read eflags | Date | Fri, 17 Dec 2021 20:39:46 +0100 |
| |
Bill,
On Thu, Dec 16 2021 at 11:55, Bill Wendling wrote: > On Wed, Dec 15, 2021 at 4:57 PM Thomas Gleixner <tglx@linutronix.de> wrote: >> Emphasis on *can*. Just claiming that this might improve things does not >> cut it. Where is the prove? >> > There are a few proofs. First, clang generates better code with the > builtin.
which is best demonstrated by showing the before and after.
> Yes, that's because clang doesn't handle the "=rm" constraint > in the same way that GCC does, but that's not really relevant (sure, > clang should correct this, but that shouldn't prevent this patch from > going, because builtins are generally better than inline assembly). > Builtins exist for a reason. The compiler's able to understand what's > going on and generate the appropriate code for it. It also gives the > compiler more freedom for optimizations. > > Secondly, this one small function has had multiple changes since its > creation, basically pinging back and forth trying to determine the > best constraints to use: > > 6abcd98f x86: irqflags consolidation > f1f029c7 x86: fix assembly constraints in native_save_fl() > ab94fcf5 x86: allow "=rm" in native_save_fl() > > The information on which form to use already exists in the compiler. > Using the builtin will save future churning and thus developers' time.
Why is the above and this
> The minimal version of GCC is now 5.1, which supports these builtins. > That wasn't the case before.
not part of the change log to avoid maintainers having to ask exactly these questions?
Thanks,
tglx
| |