[alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Stephen Warren]

Barry Song wrote at Wednesday, April 27, 2011 1:28 AM:
> The newest compiliers can optimize pll calculation in several codecs into
> __aeabi__uldivmod which doesn't exist in kernel.
> Then the link will fail:
> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!
> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8940.ko] undefined!
> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8510.ko] undefined!
> This patch prevent the optimizaton by insert ASM.

Aren't there compiler flags that tell gcc it isn't operating in a hosted(?)
environment, and hence not to emit calls to these functions? If so, I
imagine they should be added to the kernel's core (or ARM arch ) makefiles.

I doubt __aeabi_uldivmod is the only function of this type. How was this
solved for other such functions; does the kernel implement the AEABI
functions, and this implementation is simply missing?

But yes either way, ask on the main kernel or ARM kernel mailing list
(ARM now CC'd)

diff --git a/sound/soc/codecs/wm8510.c b/sound/soc/codecs/wm8510.c
index db0dced..a636b15 100644
--- a/sound/soc/codecs/wm8510.c
+++ b/sound/soc/codecs/wm8510.c
@@ -258,6 +258,12 @@ static void pll_factors(unsigned int target, unsigned int source)
 	Nmod = target % source;
 	Kpart = FIXED_PLL_SIZE * (long long)Nmod;
 
+	/*
+	 * The following asm() prevents the compiler from optimising
+	 * into a standard EABI function __aeabi__uldivmod()
+	 */
+	asm("" : "+r"(source));
+
 	do_div(Kpart, source);
 
 	K = Kpart & 0xFFFFFFFF;

-- 
nvpublic

[alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Mark Brown]

On Wed, Apr 27, 2011 at 07:59:39AM -0700, Stephen Warren wrote:

> Aren't there compiler flags that tell gcc it isn't operating in a hosted(?)
> environment, and hence not to emit calls to these functions? If so, I
> imagine they should be added to the kernel's core (or ARM arch ) makefiles.

IIRC there's some intrinsics (usually for operations like divisions)
which GCC expects to be provided even in a free standing environment.

[alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Barry Song]

2011/4/27 Stephen Warren <swarren@nvidia.com>:
> Barry Song wrote at Wednesday, April 27, 2011 1:28 AM:
>> The newest compiliers can optimize pll calculation in several codecs into
>> __aeabi__uldivmod which doesn't exist in kernel.
>> Then the link will fail:
>> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!
>> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8940.ko] undefined!
>> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8510.ko] undefined!
>> This patch prevent the optimizaton by insert ASM.
>
> Aren't there compiler flags that tell gcc it isn't operating in a hosted(?)
> environment, and hence not to emit calls to these functions? If so, I
> imagine they should be added to the kernel's core (or ARM arch ) makefiles.

not real. it is right for gcc to call __aeabi_uldivmod while it think
it is good. most time, people change kernel codes to avoid this kind
of optimization:

http://comments.gmane.org/gmane.linux.kernel/965262

Another example is time.h:

{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {
+ /* The following asm() prevents the compiler from
+ * optimising this loop into a modulo operation. */
+ asm("" : "+r"(ns));
+
ns -= NSEC_PER_SEC;
a->tv_sec++;
}

>
> I doubt __aeabi_uldivmod is the only function of this type. How was this
> solved for other such functions; does the kernel implement the AEABI
> functions, and this implementation is simply missing?
>
> But yes either way, ask on the main kernel or ARM kernel mailing list
> (ARM now CC'd)
>
> diff --git a/sound/soc/codecs/wm8510.c b/sound/soc/codecs/wm8510.c
> index db0dced..a636b15 100644
> --- a/sound/soc/codecs/wm8510.c
> +++ b/sound/soc/codecs/wm8510.c
> @@ -258,6 +258,12 @@ static void pll_factors(unsigned int target, unsigned int source)
> ? ? ? ?Nmod = target % source;
> ? ? ? ?Kpart = FIXED_PLL_SIZE * (long long)Nmod;
>
> + ? ? ? /*
> + ? ? ? ?* The following asm() prevents the compiler from optimising
> + ? ? ? ?* into a standard EABI function __aeabi__uldivmod()
> + ? ? ? ?*/
> + ? ? ? asm("" : "+r"(source));
> +
> ? ? ? ?do_div(Kpart, source);
>
> ? ? ? ?K = Kpart & 0xFFFFFFFF;
>
> --
> nvpublic
>
>

[alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Barry Song]

2011/4/27 Stephen Warren <swarren@nvidia.com>:
> Barry Song wrote at Wednesday, April 27, 2011 1:28 AM:
>> The newest compiliers can optimize pll calculation in several codecs into
>> __aeabi__uldivmod which doesn't exist in kernel.
>> Then the link will fail:
>> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!
>> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8940.ko] undefined!
>> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8510.ko] undefined!
>> This patch prevent the optimizaton by insert ASM.
>
> Aren't there compiler flags that tell gcc it isn't operating in a hosted(?)
> environment, and hence not to emit calls to these functions? If so, I
> imagine they should be added to the kernel's core (or ARM arch ) makefiles.
>
> I doubt __aeabi_uldivmod is the only function of this type. How was this
> solved for other such functions; does the kernel implement the AEABI
> functions, and this implementation is simply missing?

__aeabi_uldivmod is not implemented by kernel, others are implemented
in arch/arm/lib/lib1funcs.S:
extern void __aeabi_idiv(void);
extern void __aeabi_idivmod(void);
extern void __aeabi_lasr(void);
extern void __aeabi_llsl(void);
extern void __aeabi_llsr(void);
extern void __aeabi_lmul(void);
extern void __aeabi_uidiv(void);
extern void __aeabi_uidivmod(void);
extern void __aeabi_ulcmp(void);

>
> But yes either way, ask on the main kernel or ARM kernel mailing list
> (ARM now CC'd)
>
> diff --git a/sound/soc/codecs/wm8510.c b/sound/soc/codecs/wm8510.c
> index db0dced..a636b15 100644
> --- a/sound/soc/codecs/wm8510.c
> +++ b/sound/soc/codecs/wm8510.c
> @@ -258,6 +258,12 @@ static void pll_factors(unsigned int target, unsigned int source)
> ? ? ? ?Nmod = target % source;
> ? ? ? ?Kpart = FIXED_PLL_SIZE * (long long)Nmod;
>
> + ? ? ? /*
> + ? ? ? ?* The following asm() prevents the compiler from optimising
> + ? ? ? ?* into a standard EABI function __aeabi__uldivmod()
> + ? ? ? ?*/
> + ? ? ? asm("" : "+r"(source));
> +
> ? ? ? ?do_div(Kpart, source);
>
> ? ? ? ?K = Kpart & 0xFFFFFFFF;
>
> --
> nvpublic
>
>

[alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

[Nicolas Pitre]

On Wed, 27 Apr 2011, Barry Song wrote:

> 2011/4/27 Stephen Warren <swarren@nvidia.com>:
> > Barry Song wrote at Wednesday, April 27, 2011 1:28 AM:
> >> The newest compiliers can optimize pll calculation in several codecs into
> >> __aeabi__uldivmod which doesn't exist in kernel.
> >> Then the link will fail:
> >> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!
> >> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8940.ko] undefined!
> >> ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8510.ko] undefined!
> >> This patch prevent the optimizaton by insert ASM.
> >
> > Aren't there compiler flags that tell gcc it isn't operating in a hosted(?)
> > environment, and hence not to emit calls to these functions? If so, I
> > imagine they should be added to the kernel's core (or ARM arch ) makefiles.
> >
> > I doubt __aeabi_uldivmod is the only function of this type. How was this
> > solved for other such functions; does the kernel implement the AEABI
> > functions, and this implementation is simply missing?
> 
> __aeabi_uldivmod is not implemented by kernel, others are implemented
> in arch/arm/lib/lib1funcs.S:
> extern void __aeabi_idiv(void);
> extern void __aeabi_idivmod(void);
> extern void __aeabi_lasr(void);
> extern void __aeabi_llsl(void);
> extern void __aeabi_llsr(void);
> extern void __aeabi_lmul(void);
> extern void __aeabi_uidiv(void);
> extern void __aeabi_uidivmod(void);
> extern void __aeabi_ulcmp(void);

This is not the point.  uldivmod will not be implemented on purpose 
because this is a kernel policy _not_ to create any code that would 
require it.

And the description above is wrong too.  It's not about "the newest 
compiler can optimize ..." but rather "the newest compiler has a bug 
that leave a stray reference to __aeabi_uldivmod in the compiled 
object."  As far as I'm concerned, the code is fine as is.  It is the 
compiler that is wrong.


Nicolas