* Uros Bizjak <[email protected]> wrote:
> On Mon, Jul 27, 2015 at 5:54 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Uros Bizjak <[email protected]> wrote:
> >
> >> On Mon, Jul 27, 2015 at 5:40 PM, Ingo Molnar <[email protected]> wrote:
> >> >
> >> > * Uros Bizjak <[email protected]> wrote:
> >> >
> >> >> From: Uros Bizjak <[email protected]>
> >> >>
> >> >> 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 <[email protected]>
> >> >> ---
> >> >> 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
Ok, great!
One more request: please make it similar to how we handle other, similar
compiler
features and introduce an interim macro like:
#ifdef __GCC_ASM_FLAG_OUTPUTS__
# define CC_HAVE_ASM_FLAG_OUTPUTS
#endif
in a suitable spot in include/linux/compiler-gcc.h, and use
CC_HAVE_ASM_FLAG_OUTPUTS in the other places.
this makes it easier to disable/enable this feature centrally, and it might
enable
other compilers to introduce a similar feature.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
