Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
2011/4/26 Nicolas Pitre :
> On Tue, 26 Apr 2011, Michael Hope wrote:
>
>> Yip, so the compiler spots these two lines:
>> Ndiv = target / source;
>> Nmod = target % source;
>>
>> and turns them into
>> Ndiv, Nmod = __aeabi_uldivmod(target, source)
>
> Why would gcc do that? All four variables involved here are of type
> unsigned int, no unsigned long long. Seems to me that __aeabi_uidivmod
> should have been used here instead.
I think we should dig into do_div, as i have reported, add a line
"asm("" : "+r"(source));" before "do_div(Kpart, source);" can also
avoid this optimization.
So the __aeabi_uldivmod should be in do_div.
>
>
> Nicolas
>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Performance meeting agenda for today.
Hi, Agenda for today's performance call . Sorry about the last minute posting and I'll put this in the wiki soon enough. 1. Sync-up on what's been happening around the group: a. Coremark regressions. b. Thumb2 constants patch. c. divmodsi4 and vfp register moves. d. DENBench investigations. 2. Planning for the summit and turning some of the ideas into blueprints. 3. AOB. cheers Ramana ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bug in linaros implementation of vset_lane intrinsics
Hi All,
This is based upon gcc version 4.5.3 (20110221 pre-release)
Any help appreciated
This shows a bug in the Linaro gcc compiler with the Arm NEON
vset_lane intrinsic
Note in the objdump that the vmov.8 instruction that places the
value in the vector for the non-q version uses 1 where it should use
2 and 3:
18: ee410bb0vmov.8 d17[1], r0
1c: ee420bb0vmov.8 d18[1], r0
20: ee400b90vmov.8 d16[0], r0
3c: ee440bb0vmov.8 d20[1], r0
For the q version the vmov.8 instructions are correct:
40: ee420bf0vmov.8 d18[3], r0
54: ee420bd0vmov.8 d18[2], r0
64: ee400b90vmov.8 d16[0], r0
70: ee420bb0vmov.8 d18[1], r0
/* Source code */
#include
static uint8x8_t vec[5]
static uint8x16_t qvec[5];
void set(uint8_t value)
{
vec[1] = vset_lane_u8(value, vec[0], 3);
vec[2] = vset_lane_u8(value, vec[0], 2);
vec[3] = vset_lane_u8(value, vec[0], 1);
vec[4] = vset_lane_u8(value, vec[0], 0);
qvec[1] = vsetq_lane_u8(value, qvec[0], 3);
qvec[2] = vsetq_lane_u8(value, qvec[0], 2);
qvec[3] = vsetq_lane_u8(value, qvec[0], 1);
qvec[4] = vsetq_lane_u8(value, qvec[0], 0);
}
Thx
Lee
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 18th - 21st April
Merged & tested the outstanding merge requests into Linaro GCC. Spin the Linaro GCC 4.5 and 4.6 releases. Uploaded the tarballs to Michael. Submitted a patch upstream that removed some redundant code that had confused me a introduced a bug into my Thumb2 constants patch. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03756.html This patch is now approved and committed upstream. I'll commit it internally when the rest of my ARM/Thumb constant handling changes are upstream. Worked on addressing RichardE's concerns with my Thumb2 constants patch. Tried to split it into smaller chunks, and rename the constraints. Posted the patches upstream: 1. a small patch upstream to clean up MOWV support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03768.html (Now approved and committed.) 2. ADDW and SUBW support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html 3. Replicated constants for constant splitting. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html Committed upstream Dan's Vector shift test cases patch that was approved last week. Pushed the same patch to Linaro GCC 4.6. Upstream patched requiring review: * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * ARM EABI half-precision functions (reposted 2011-04-14) http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html * ARM Thumb2 addw/subw support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html * ARM Thumb2 Replicated constants http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Sessions for the summit
On 20/04/11 04:37, Michael Hope wrote: I've put your names against the sessions as follows: Andrew: Broad tuning I've added some work-items to the wiki page. Please let me know if this is sufficient. Thanks Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
On 26/04/11 03:39, Nicolas Pitre wrote: But I digress. This is just to say that gcc shouldn't pull __aeabi_uldivmod in this case because: There isn't a library call (or instruction) for a straight 'mod' operation, so GCC always has to use 'divmod', no exceptions. In any case, optimization of a div and a mod into a single call is problematic, at best, so it's unlikely that's happening. See GCC PR43721. Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
On Wed, Apr 27, 2011 at 12:23 AM, Andrew Stubbs wrote: > On 26/04/11 03:39, Nicolas Pitre wrote: >> >> But I digress. This is just to say that gcc shouldn't pull >> __aeabi_uldivmod in this case because: > > There isn't a library call (or instruction) for a straight 'mod' operation, > so GCC always has to use 'divmod', no exceptions. > > In any case, optimization of a div and a mod into a single call is > problematic, at best, so it's unlikely that's happening. See GCC PR43721. Ah, sorry. So the divmod call is there due to the modulo operation only. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
On Tue, Apr 26, 2011 at 1:48 PM, Barry Song <21cn...@gmail.com> wrote:
> 2011/4/26 Barry Song <21cn...@gmail.com>:
>> Hi Michael,
>>
>> 2011/4/26 Michael Hope :
>>> Hi Barry. I think the toolchain is operating correctly here. The
>>> current version recognises a divide followed by a modulo and optimises
>>> this into a call to the standard EABI function __aeabi__uldivmod().
>>> Note the code:
>>>
>>> do_div(Kpart, source);
>>>
>>> K = Kpart & 0x;
>>>
>>> /* Check if we need to round */
>>> if ((K % 10) >= 5)
>>> K += 5;
>>>
>>> This function is provided by libgcc for normal applications. The
>>> kernel provides it's own versions in arch/arm/lib/lib1funcs.s but is
>>> missing __aeabi_uldivmod (note the 'l' for 64 bit).
>> In fact the problem happen ealier:
>>
>> if (Ndiv < 6) {
>> source /= 2;
>> pll_div->pre_div = 1;
>> Ndiv = target / source;
>> } else
>> pll_div->pre_div = 0;
>>
>> if ((Ndiv < 6) || (Ndiv > 12))
>> printk(KERN_WARNING
>> "WM8974 N value %u outwith recommended range!\n",
>> Ndiv);
>>
>> pll_div->n = Ndiv;
>> Nmod = target % source;
>> Kpart = FIXED_PLL_SIZE * (long long)Nmod;
>>
>> do_div(Kpart, source);
>>
>> If commenting "source /= 2", the problem disappear.
>>
>>
> Or if adding one line before do_div, all will be ok.
> asm("" : "+r"(source));
> do_div(Kpart, source);
Hi Barry. I can reproduce the problem in Linaro GCC 4.5-2011.04 and
GCC 4.5.2. It does not exist in GCC 4.6.0. wm8974_set_dai_pll()
inlines the call to pll_factors() and leaves a .globl reference to
__aeabi_uldivmod in the code. This function is never called.
Marking pll_factors() as __attribute__((noinline)) also works around
the problem.
I've logged http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 upstream
and recorded this as LP: #771551.
-- Michael
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko
On Wed, 27 Apr 2011, Michael Hope wrote: > On Wed, Apr 27, 2011 at 12:23 AM, Andrew Stubbs > wrote: > > On 26/04/11 03:39, Nicolas Pitre wrote: > >> > >> But I digress. This is just to say that gcc shouldn't pull > >> __aeabi_uldivmod in this case because: > > > > There isn't a library call (or instruction) for a straight 'mod' operation, > > so GCC always has to use 'divmod', no exceptions. > > > > In any case, optimization of a div and a mod into a single call is > > problematic, at best, so it's unlikely that's happening. See GCC PR43721. > > Ah, sorry. So the divmod call is there due to the modulo operation only. Makes sense. Now... why is the uldivmod version used over the uidivmod version when all the variables involved are only 32 bit wide? Nicolas___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
