[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFULd4ZiyhbAFs_WzE3NLqiLz87DwdAjay65F0X8P44RQ3Y_2Q@mail.gmail.com>
Date: Mon, 27 Jul 2015 17:59:00 +0200
From: Uros Bizjak <ubizjak@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Uros Bizjak <uros_bizjak1@....net>, linux-kernel@...r.kernel.org,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH] x86: Introduce ASM flags to bitops
On Mon, Jul 27, 2015 at 5:54 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Uros Bizjak <ubizjak@...il.com> wrote:
>
>> On Mon, Jul 27, 2015 at 5:40 PM, Ingo Molnar <mingo@...nel.org> wrote:
>> >
>> > * Uros Bizjak <uros_bizjak1@....net> wrote:
>> >
>> >> From: Uros Bizjak <ubizjak@...il.com>
>> >>
>> >> This patch introduces GCC ASM flags to bitops. Instead of e.g.
>> >>
>> >> 136d7: 48 0f a3 3d 00 00 00 bt %rdi,0x0(%rip)
>> >> 136de: 00
>> >> 136df: 19 ff sbb %edi,%edi
>> >> 136e1: 85 ff test %edi,%edi
>> >> 136e3: 0f 95 c0 setne %al
>> >>
>> >> following code is generated:
>> >>
>> >> 13767: 48 0f a3 3d 00 00 00 bt %rdi,0x0(%rip)
>> >> 1376e: 00
>> >> 1376f: 0f 92 c0 setb %al
>> >>
>> >> Similar improvement can be seen in following code:
>> >>
>> >> 7a6c: 48 0f a3 11 bt %rdx,(%rcx)
>> >> 7a70: 19 d2 sbb %edx,%edx
>> >> 7a72: 85 d2 test %edx,%edx
>> >> 7a74: 74 eb je 7a61
>> >>
>> >> which becomes:
>> >>
>> >> 7a8c: 48 0f a3 11 bt %rdx,(%rcx)
>> >> 7a90: 73 ef jae 7a81
>> >>
>> >> Signed-off-by: Uros Bizjak <ubizjak@...il.com>
>> >> ---
>> >> arch/x86/include/asm/bitops.h | 26 ++++++++++++++++++++++++--
>> >> arch/x86/include/asm/percpu.h | 18 +++++++++++++++++-
>> >> arch/x86/include/asm/signal.h | 6 ++++++
>> >> arch/x86/include/asm/sync_bitops.h | 18 ++++++++++++++++++
>> >> 4 files changed, 65 insertions(+), 3 deletions(-)
>> >
>> > Nothing in your patch seems to be setting __GCC_ASM_FLAG_OUTPUTS__, and the patch
>> > does not seem to be mailed as part of a larger series ...
>> >
>> > So how is this supposed to work?
>>
>> GCC version 6+ will automatically define __GCC_ASM_FLAG_OUTPUTS__ when
>> this feature is supported. Please see [1] for RFC GCC patch series and
>> [2] for final committed patch.
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00594.html
>> [2] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02087.html
>
> Ok, great. This information should be part of the changelog and such, as it's not
> obvious.
No problem, I'll add this information and send a v2 patch.
> Does the GCC project treat this as an ABI kind of thing, i.e. can the kernel rely
> on it from now on, without the GCC side semantics of this feature not ever
> changing and breaking the kernel?
Yes. It was discussed and agreed between GCC and kernel people (HPA)
on GCC mailing list. Please see [3].
[3] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00725.html
Uros.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists