Re: PROPOSAL: Extend inline asm syntax with size spec
Hi Peter, On Wed, Oct 31, 2018 at 9:58 PM Peter Zijlstra wrote: > > On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote: > > Ok, > > > > with Segher's help I've been playing with his patch ontop of bleeding > > edge gcc 9 and here are my observations. Please double-check me for > > booboos so that they can be addressed while there's time. > > > > So here's what I see ontop of 4.19-rc7: > > > > First marked the alternative asm() as inline and undeffed the "inline" > > keyword. I need to do that because of the funky games we do with > > "inline" redefinitions in include/linux/compiler_types.h. > > > > And Segher hinted at either doing: > > > > asm volatile inline(... > > > > or > > > > asm volatile __inline__(... > > > > but both "inline" variants are defined as macros in that file. > > > > Which means we either need to #undef inline before using it in asm() or > > come up with something cleverer. > > # git grep -e "\<__inline__\>" | wc -l > 488 > # git grep -e "\<__inline\>" | wc -l > 56 > # git grep -e "\" | wc -l > 69598 > > And we already have scripts/checkpatch.pl: > > # Check for __inline__ and __inline, prefer inline > > Which suggests we do: > > git grep -l "\<__inline\(\|__\)\>" | while read file > do > sed -i -e 's/\<__inline\(\|__\)\>/inline/g' $file > done > > and get it over with. Do you have a plan to really do this? This is a nice cleanup anyway. I think the last minute of MW is a good timing for the global replacement like this. > > Anyway, with the below patch, I get: > >textdata bss dec hex filename > 173851835064780 1953892 244038551745f8f > defconfig-build/vmlinux > 173856785064780 1953892 24404350174617e > defconfig-build/vmlinux > > Which shows we inline more (look for asm_volatile for the actual > changes). > > > So yes, this seems like something we could work with. > > --- > Documentation/trace/tracepoint-analysis.rst| 2 +- > Documentation/translations/ja_JP/SubmittingPatches | 4 +-- > Documentation/translations/zh_CN/SubmittingPatches | 4 +-- > arch/alpha/include/asm/atomic.h| 12 +++ > arch/alpha/include/asm/bitops.h| 6 ++-- > arch/alpha/include/asm/compiler.h | 4 +-- > arch/alpha/include/asm/dma.h | 22 ++-- > arch/alpha/include/asm/floppy.h| 4 +-- > arch/alpha/include/asm/irq.h | 2 +- > arch/alpha/include/asm/local.h | 4 +-- > arch/alpha/include/asm/smp.h | 2 +- > arch/arm/mach-iop32x/include/mach/uncompress.h | 2 +- > arch/arm/mach-iop33x/include/mach/uncompress.h | 2 +- > arch/arm/mach-ixp4xx/include/mach/uncompress.h | 2 +- > arch/ia64/hp/common/sba_iommu.c| 2 +- > arch/ia64/hp/sim/simeth.c | 2 +- > arch/ia64/include/asm/atomic.h | 8 ++--- > arch/ia64/include/asm/bitops.h | 34 +- > arch/ia64/include/asm/delay.h | 14 > arch/ia64/include/asm/irq.h| 2 +- > arch/ia64/include/asm/page.h | 2 +- > arch/ia64/include/asm/sn/leds.h| 2 +- > arch/ia64/include/asm/uaccess.h| 4 +-- > arch/ia64/include/uapi/asm/rse.h | 12 +++ > arch/ia64/include/uapi/asm/swab.h | 6 ++-- > arch/ia64/oprofile/backtrace.c | 4 +-- > arch/m68k/include/asm/blinken.h| 2 +- > arch/m68k/include/asm/checksum.h | 2 +- > arch/m68k/include/asm/dma.h| 32 - > arch/m68k/include/asm/floppy.h | 8 ++--- > arch/m68k/include/asm/nettel.h | 8 ++--- > arch/m68k/mac/iop.c| 14 > arch/mips/include/asm/atomic.h | 16 - > arch/mips/include/asm/checksum.h | 2 +- > arch/mips/include/asm/dma.h| 20 +-- > arch/mips/include/asm/jazz.h | 2 +- > arch/mips/include/asm/local.h | 4 +-- > arch/mips/include/asm/string.h | 8 ++--- > arch/mips/kernel/binfmt_elfn32.c | 2 +- > arch/nds32/include/asm/swab.h | 4 +-- > arch/parisc/include/asm/atomic.h | 20 +-- > arch/parisc/include/asm/bitops.h | 18 +- > arch/parisc/include/asm/checksum.h | 4 +-- > arch/parisc/include/asm/compat.h | 2 +- > arch/parisc/include/asm/delay.h| 2 +- > arch/parisc/include/asm/dma.h | 20 +-- > arch/parisc/include/asm/ide.h | 8 ++--- > arch/parisc/include/asm/irq.h
Re: PROPOSAL: Extend inline asm syntax with size spec
Hi Segher, On Sun, Dec 2, 2018 at 3:48 PM Segher Boessenkool wrote: > > On Fri, Nov 30, 2018 at 10:06:02AM +0100, Boris Petkov wrote: > > On November 29, 2018 1:25:02 PM GMT+01:00, Segher Boessenkool > > wrote: > > >This will only be fixed from GCC 9 on, if the compiler adopts it. The > > >kernel wants to support ancient GCC, so it will need to have a > > >workaround > > >for older GCC versions anyway. > > > > What about backporting it, like Richard says? > > Let me first get it into GCC trunk :-) > > It should backport fine, sure; and I'll work on that. > Now, I can see it in the GCC trunk. Hooray!!! commit 6de46ad5326fc5e6b730a2feb8c62d09c1561f92 Author: segher Date: Thu Dec 6 17:56:58 2018 + asm inline The Linux kernel people want a feature that makes GCC pretend some inline assembler code is tiny (while it would think it is huge), so that such code will be inlined essentially always instead of essentially never. This patch lets you say "asm inline" instead of just "asm", with the result that that inline assembler is always counted as minimum cost for inlining. It implements this for C and C++, making "inline" another asm-qualifier (supplementing "volatile" and "goto"). -- Best Regards Masahiro Yamada
Re: PROPOSAL: Extend inline asm syntax with size spec
Ping.
This is a good point in time, methinks, where kernel folk on CC here
should have a look at this and speak up whether it is useful for us in
this form.
Frankly, I'm a bit unsure on the aspect of us using this and supporting
old compilers which don't have it and new compilers which do. Because
the old compilers should get to see the now upstreamed assembler macros
and the new compilers will simply inline the "asm volatile inline"
constructs. And how ugly that would become...
I guess we can try this with smaller macros first and keep them all
nicely hidden in header files.
On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> Ok,
>
> with Segher's help I've been playing with his patch ontop of bleeding
> edge gcc 9 and here are my observations. Please double-check me for
> booboos so that they can be addressed while there's time.
>
> So here's what I see ontop of 4.19-rc7:
>
> First marked the alternative asm() as inline and undeffed the "inline"
> keyword. I need to do that because of the funky games we do with
> "inline" redefinitions in include/linux/compiler_types.h.
>
> And Segher hinted at either doing:
>
> asm volatile inline(...
>
> or
>
> asm volatile __inline__(...
>
> but both "inline" variants are defined as macros in that file.
>
> Which means we either need to #undef inline before using it in asm() or
> come up with something cleverer.
>
> Anyway, did this:
>
> ---
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index 4cd6a3b71824..7c0639087da7 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -165,11 +165,13 @@ static inline int alternatives_text_reserved(void
> *start, void *end)
> * For non barrier like inlines please define new variants
> * without volatile and memory clobber.
> */
> +
> +#undef inline
> #define alternative(oldinstr, newinstr, feature) \
> - asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
> + asm volatile inline(ALTERNATIVE(oldinstr, newinstr, feature) : : :
> "memory")
>
> #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
> - asm volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2,
> feature2) ::: "memory")
> + asm volatile inline(ALTERNATIVE_2(oldinstr, newinstr1, feature1,
> newinstr2, feature2) ::: "memory")
>
> /*
> * Alternative inline assembly with input.
> ---
>
> Build failed at link time with:
>
> arch/x86/boot/compressed/cmdline.o: In function `native_save_fl':
> cmdline.c:(.text+0x0): multiple definition of `native_save_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1e0): first defined here
> arch/x86/boot/compressed/cmdline.o: In function `native_restore_fl':
> cmdline.c:(.text+0x10): multiple definition of `native_restore_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1f0): first defined here
> arch/x86/boot/compressed/error.o: In function `native_save_fl':
> error.c:(.text+0x0): multiple definition of `native_save_fl'
>
> which I had to fix with this:
>
> ---
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index 15450a675031..0d772598c37c 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -14,8 +14,7 @@
> */
>
> /* Declaration required for gcc < 4.9 to prevent -Werror=missing-prototypes
> */
> -extern inline unsigned long native_save_fl(void);
> -extern inline unsigned long native_save_fl(void)
> +static inline unsigned long native_save_fl(void)
> {
> unsigned long flags;
>
> @@ -33,8 +32,7 @@ ex
> ---
>
> That "extern inline" declaration looks fishy to me anyway, maybe not really
> needed ? Apparently, gcc < 4.9 complains with -Werror=missing-prototypes...
>
> Then the build worked and the results look like this:
>
>textdata bss dec hex filename
> 172873845040656 2019532 2434757217383b4 vmlinux-before
> 172880205040656 2015436 243441121737630 vmlinux-2nd-version
>
> so some inlining must be happening.
>
> Then I did this:
>
> ---
> diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
> index 9c5606d88f61..a0170344cf08 100644
> --- a/arch/x86/lib/usercopy_64.c
> +++ b/arch/x86/lib/usercopy_64.c
> @@ -20,7 +20,7 @@ unsigned long __clear_user(void __user *addr, unsigned long
> size)
> /* no memory constraint because it doesn't change any memory gcc knows
>about */
> stac();
> - asm volatile(
> + asm volatile inline(
> " testq %[size8],%[size8]\n"
> " jz 4f\n"
> "0: movq $0,(%[dst])\n"
> ---
>
> to force inlining of a somewhat bigger asm() statement. And yap, more
> got inlined:
>
>textdata bss dec hex filename
> 172873845040656 2019532 2434757217383b4 vmlinux-before
> 17288020
Re: PROPOSAL: Extend inline asm syntax with size spec
Ping.
This is a good point in time, methinks, where kernel folk on CC here
should have a look at this and speak up whether it is useful for us in
this form.
Frankly, I'm a bit unsure on the aspect of us using this and supporting
old compilers which don't have it and new compilers which do. Because
the old compilers should get to see the now upstreamed assembler macros
and the new compilers will simply inline the "asm volatile inline"
constructs. And how ugly that would become...
I guess we can try this with smaller macros first and keep them all
nicely hidden in header files.
On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> Ok,
>
> with Segher's help I've been playing with his patch ontop of bleeding
> edge gcc 9 and here are my observations. Please double-check me for
> booboos so that they can be addressed while there's time.
>
> So here's what I see ontop of 4.19-rc7:
>
> First marked the alternative asm() as inline and undeffed the "inline"
> keyword. I need to do that because of the funky games we do with
> "inline" redefinitions in include/linux/compiler_types.h.
>
> And Segher hinted at either doing:
>
> asm volatile inline(...
>
> or
>
> asm volatile __inline__(...
>
> but both "inline" variants are defined as macros in that file.
>
> Which means we either need to #undef inline before using it in asm() or
> come up with something cleverer.
>
> Anyway, did this:
>
> ---
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index 4cd6a3b71824..7c0639087da7 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -165,11 +165,13 @@ static inline int alternatives_text_reserved(void
> *start, void *end)
> * For non barrier like inlines please define new variants
> * without volatile and memory clobber.
> */
> +
> +#undef inline
> #define alternative(oldinstr, newinstr, feature) \
> - asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
> + asm volatile inline(ALTERNATIVE(oldinstr, newinstr, feature) : : :
> "memory")
>
> #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
> - asm volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2,
> feature2) ::: "memory")
> + asm volatile inline(ALTERNATIVE_2(oldinstr, newinstr1, feature1,
> newinstr2, feature2) ::: "memory")
>
> /*
> * Alternative inline assembly with input.
> ---
>
> Build failed at link time with:
>
> arch/x86/boot/compressed/cmdline.o: In function `native_save_fl':
> cmdline.c:(.text+0x0): multiple definition of `native_save_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1e0): first defined here
> arch/x86/boot/compressed/cmdline.o: In function `native_restore_fl':
> cmdline.c:(.text+0x10): multiple definition of `native_restore_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1f0): first defined here
> arch/x86/boot/compressed/error.o: In function `native_save_fl':
> error.c:(.text+0x0): multiple definition of `native_save_fl'
>
> which I had to fix with this:
>
> ---
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index 15450a675031..0d772598c37c 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -14,8 +14,7 @@
> */
>
> /* Declaration required for gcc < 4.9 to prevent -Werror=missing-prototypes
> */
> -extern inline unsigned long native_save_fl(void);
> -extern inline unsigned long native_save_fl(void)
> +static inline unsigned long native_save_fl(void)
> {
> unsigned long flags;
>
> @@ -33,8 +32,7 @@ ex
> ---
>
> That "extern inline" declaration looks fishy to me anyway, maybe not really
> needed ? Apparently, gcc < 4.9 complains with -Werror=missing-prototypes...
>
> Then the build worked and the results look like this:
>
>textdata bss dec hex filename
> 172873845040656 2019532 2434757217383b4 vmlinux-before
> 172880205040656 2015436 243441121737630 vmlinux-2nd-version
>
> so some inlining must be happening.
>
> Then I did this:
>
> ---
> diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
> index 9c5606d88f61..a0170344cf08 100644
> --- a/arch/x86/lib/usercopy_64.c
> +++ b/arch/x86/lib/usercopy_64.c
> @@ -20,7 +20,7 @@ unsigned long __clear_user(void __user *addr, unsigned long
> size)
> /* no memory constraint because it doesn't change any memory gcc knows
>about */
> stac();
> - asm volatile(
> + asm volatile inline(
> " testq %[size8],%[size8]\n"
> " jz 4f\n"
> "0: movq $0,(%[dst])\n"
> ---
>
> to force inlining of a somewhat bigger asm() statement. And yap, more
> got inlined:
>
>textdata bss dec hex filename
> 172873845040656 2019532 2434757217383b4 vmlinux-before
> 17288020
Re: PROPOSAL: Extend inline asm syntax with size spec
On Wed, 10 Oct 2018, Nadav Amit wrote:
> at 7:53 AM, Segher Boessenkool wrote:
>
> > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> >> On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> >>> On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
> >> Now, Richard suggested doing something like:
> >>
> >> 1) inline asm ("...")
> >
> > What would the semantics of this be?
>
> The size of the inline asm wouldn't be counted towards the inliner size
> limits (or be counted as "1").
> >>>
> >>> That sounds like a good option.
> >>
> >> Yes, I also like it for simplicity. It also avoids the requirement
> >> of translating the number (in bytes?) given by the user to
> >> "number of GIMPLE instructions" as needed by the inliner.
> >
> > This patch implements this, for C only so far. And the syntax is
> > "asm inline", which is more in line with other syntax.
> >
> > How does this look?
>
> It looks good to me in general. I have a couple of reservations, but I
> suspect you will not want to address them:
>
> 1. It is not backward compatible, requiring a C macro to wrap it, as the
> kernel might be built with different compilers.
>
> 2. It is specific to asm. I do not have in mind another use case (excluding
> the __builtin_constant_p), but it would be nicer IMHO to have a builtin
> saying “ignore the cost of this statement” for the matter of optimizations.
The only easy possibility that comes to my mid is sth like
__attribute__((always_inline, zero_cost)) foo ()
{
... your stmts ...
}
and us, upon inlining, marking the inlined stmts properly. That would
also work for the asm() case and it would be backwards compatible
(well, you'd get a diagnostic for the unknown zero_cost attribute).
There's the slight complication that if you have, say
_1 = _2 * 3; // zero-cost
_4 = _1 * 2;
and optimization ends up combining those to
_4 = _2 * 6;
then is this stmt supposed to be zero-cost or not? Compare that to
_1 = _2 * 3;
_4 = _1 * 2; // zero-cost
So outside of asm() there are new issues that come up with respect
to expected (cost) semantics.
Richard.
Re: PROPOSAL: Extend inline asm syntax with size spec
On Wed, 10 Oct 2018, Nadav Amit wrote:
> at 7:53 AM, Segher Boessenkool wrote:
>
> > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> >> On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> >>> On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
> >> Now, Richard suggested doing something like:
> >>
> >> 1) inline asm ("...")
> >
> > What would the semantics of this be?
>
> The size of the inline asm wouldn't be counted towards the inliner size
> limits (or be counted as "1").
> >>>
> >>> That sounds like a good option.
> >>
> >> Yes, I also like it for simplicity. It also avoids the requirement
> >> of translating the number (in bytes?) given by the user to
> >> "number of GIMPLE instructions" as needed by the inliner.
> >
> > This patch implements this, for C only so far. And the syntax is
> > "asm inline", which is more in line with other syntax.
> >
> > How does this look?
>
> It looks good to me in general. I have a couple of reservations, but I
> suspect you will not want to address them:
>
> 1. It is not backward compatible, requiring a C macro to wrap it, as the
> kernel might be built with different compilers.
>
> 2. It is specific to asm. I do not have in mind another use case (excluding
> the __builtin_constant_p), but it would be nicer IMHO to have a builtin
> saying “ignore the cost of this statement” for the matter of optimizations.
The only easy possibility that comes to my mid is sth like
__attribute__((always_inline, zero_cost)) foo ()
{
... your stmts ...
}
and us, upon inlining, marking the inlined stmts properly. That would
also work for the asm() case and it would be backwards compatible
(well, you'd get a diagnostic for the unknown zero_cost attribute).
There's the slight complication that if you have, say
_1 = _2 * 3; // zero-cost
_4 = _1 * 2;
and optimization ends up combining those to
_4 = _2 * 6;
then is this stmt supposed to be zero-cost or not? Compare that to
_1 = _2 * 3;
_4 = _1 * 2; // zero-cost
So outside of asm() there are new issues that come up with respect
to expected (cost) semantics.
Richard.
Re: PROPOSAL: Extend inline asm syntax with size spec
On Wed, Oct 10, 2018 at 09:12:48AM +0200, Richard Biener wrote:
> On Tue, 9 Oct 2018, Segher Boessenkool wrote:
> > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > > On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
> > > > > > > Now, Richard suggested doing something like:
> > > > > > >
> > > > > > > 1) inline asm ("...")
> > > > > >
> > > > > > What would the semantics of this be?
> > > > >
> > > > > The size of the inline asm wouldn't be counted towards the inliner
> > > > > size
> > > > > limits (or be counted as "1").
> > > >
> > > > That sounds like a good option.
> > >
> > > Yes, I also like it for simplicity. It also avoids the requirement
> > > of translating the number (in bytes?) given by the user to
> > > "number of GIMPLE instructions" as needed by the inliner.
> >
> > This patch implements this, for C only so far. And the syntax is
> > "asm inline", which is more in line with other syntax.
> >
> > How does this look?
>
> Looks good. A few nits - you need to document this in extend.texi, the
Yup.
> tree flag use needs documenting in tree-core.h,
Ah yes.
> and we need a testcase
> (I'd suggest one that shows we inline a function with "large" asm inline
> () even at -Os).
I have one. Oh, and I probably should do a comment at the one line of
code that isn't just bookkeeping ;-)
> Oh, and I don't think we want C and C++ to diverge - so you need to
> cook up C++ support as well.
Right, that's why I said "C only so far".
> Can kernel folks give this a second and third thought please so we
> don't implement sth that in the end won't satisfy you guys?
Or actually try it out and see if it has the desired effect! Nothing
beats field trials.
I'll do the C++ thing today hopefully, and send things to gcc-patches@.
Segher
Re: PROPOSAL: Extend inline asm syntax with size spec
On Wed, Oct 10, 2018 at 09:12:48AM +0200, Richard Biener wrote:
> On Tue, 9 Oct 2018, Segher Boessenkool wrote:
> > On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > > On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> > > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
> > > > > > > Now, Richard suggested doing something like:
> > > > > > >
> > > > > > > 1) inline asm ("...")
> > > > > >
> > > > > > What would the semantics of this be?
> > > > >
> > > > > The size of the inline asm wouldn't be counted towards the inliner
> > > > > size
> > > > > limits (or be counted as "1").
> > > >
> > > > That sounds like a good option.
> > >
> > > Yes, I also like it for simplicity. It also avoids the requirement
> > > of translating the number (in bytes?) given by the user to
> > > "number of GIMPLE instructions" as needed by the inliner.
> >
> > This patch implements this, for C only so far. And the syntax is
> > "asm inline", which is more in line with other syntax.
> >
> > How does this look?
>
> Looks good. A few nits - you need to document this in extend.texi, the
Yup.
> tree flag use needs documenting in tree-core.h,
Ah yes.
> and we need a testcase
> (I'd suggest one that shows we inline a function with "large" asm inline
> () even at -Os).
I have one. Oh, and I probably should do a comment at the one line of
code that isn't just bookkeeping ;-)
> Oh, and I don't think we want C and C++ to diverge - so you need to
> cook up C++ support as well.
Right, that's why I said "C only so far".
> Can kernel folks give this a second and third thought please so we
> don't implement sth that in the end won't satisfy you guys?
Or actually try it out and see if it has the desired effect! Nothing
beats field trials.
I'll do the C++ thing today hopefully, and send things to gcc-patches@.
Segher
