rdhi, rdlo and rm must all be different: say what??

rdhi, rdlo and rm must all be different: say what??

[David Brownell]

I did a build for H4, using the CodeSourcery 2007q3-53 toolchain, and:

    CC      kernel/sched.o
  /tmp/ccePvKYj.s: Assembler messages:
  /tmp/ccePvKYj.s:16: rdhi, rdlo and rm must all be different
  /tmp/ccePvKYj.s:1243: rdhi, rdlo and rm must all be different

The problem doesn't crop up with a build for OSK; different CPUs,
presumably.  It turns out these are both umull instructions; if
I "make kernel/sched.s" and build the result, the relevant lines
have different numbers but match up as:

  sched_clock:
  16:     umull   r0, r1, r0, r3  @ tmp136, jiffies.371, tmp137

  sched_slice:
          ...
  1243:   umull   r0, r1, r0, r2  @ slice.2262, slice, <variable>.load.weight

So this all looks suspiciously buglike.  Does anyone know how
to fix this issue?  Is it really a problem?

- Dave

Re: rdhi, rdlo and rm must all be different: say what??

[Felipe Balbi]

On Wed, 12 Mar 2008 16:58:40 -0800, David Brownell <david-b@pacbell.net>
wrote:
> I did a build for H4, using the CodeSourcery 2007q3-53 toolchain, and:
> 
>     CC      kernel/sched.o
>   /tmp/ccePvKYj.s: Assembler messages:
>   /tmp/ccePvKYj.s:16: rdhi, rdlo and rm must all be different
>   /tmp/ccePvKYj.s:1243: rdhi, rdlo and rm must all be different
> 
> The problem doesn't crop up with a build for OSK; different CPUs,
> presumably.  It turns out these are both umull instructions; if
> I "make kernel/sched.s" and build the result, the relevant lines
> have different numbers but match up as:
> 
>   sched_clock:
>   16:     umull   r0, r1, r0, r3  @ tmp136, jiffies.371, tmp137
> 
>   sched_slice:
>           ...
>   1243:   umull   r0, r1, r0, r2  @ slice.2262, slice,
> <variable>.load.weight
> 
> So this all looks suspiciously buglike.  Does anyone know how
> to fix this issue?  Is it really a problem?

It doesn't look like an issue:

UMULL rdlo, rdhi, rn, rm

rdlo and rdhi really must be different, but they are. Maybe CodeSourcery's
toolchain is complaining about r0 appearing twice (as rdlo and rn) but
that's
not really an issue. We can multipply r0 and r3 and place the result in r0
and r1.

Most likely to be gcc bug (or codesourcery's). Please, visit [1] for more
info.

[1] http://www.keil.com/support/man/docs/armasm/armasm_cihbjehg.htm

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

Re: rdhi, rdlo and rm must all be different: say what??

[David Brownell]

On Thursday 13 March 2008, Felipe Balbi wrote:
> >   sched_clock:
> >   16:     umull   r0, r1, r0, r3  @ tmp136, jiffies.371, tmp137
> >
> >   sched_slice:
> >           ...
> >   1243:   umull   r0, r1, r0, r2  @ slice.2262, slice,
> > <variable>.load.weight
> >
> > So this all looks suspiciously buglike.  Does anyone know how
> > to fix this issue?  Is it really a problem?
> 
> It doesn't look like an issue:
> 
> UMULL rdlo, rdhi, rn, rm

The ARM DDI (Rev I is handy) says different stuff than Keil:

  UMULL{<cond>}{S} <RdLo>, <RdHi>, <Rm>, <Rs>

Making the warning about rdlo vs rm:  both use r0.


> rdlo and rdhi really must be different, but they are. Maybe CodeSourcery's
> toolchain is complaining about r0 appearing twice (as rdlo and rn) but
> that's not really an issue. We can multipply r0 and r3 and place the result
> in r0 and r1.

The DDI casts light on the issue:

  Operand restriction
    <RdHi> and <RdLo> must be distinct registers, or the results are UNPREDICTABLE.
    Specifying the same register for either <RdHi> and <Rm>, or <RdLo> and <Rm>, was
    previously described as producing UNPREDICTABLE results. There is no restriction
    in ARMv6, and it is believed all relevant ARMv4 and ARMv5 implementations do
    not require this restriction either, because high performance multipliers read
    all their operands prior to writing back any results.

And indeed, that's what Rev E said:  "UNPREDICTABLE".  (It also did
not cover v6...)

So it looks like this warning is a definite bug:  should not issue
on v6, or with "-mcpu=arm926ej-s" (a "relevant" v5 implementation).

So I agree about ignoring this, but I'm still puzzled about why this
warning appeared.  Maybe the issue is that I upgraded to q3-53 from
an older toolchain, and just didn't do an H4 build since then... and
this bug didn't exist in that older toolchain.

- Dave



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: rdhi, rdlo and rm must all be different: say what??

[Woodruff, Richard]

Hi Dave,

> Subject: Re: rdhi, rdlo and rm must all be different: say what??
> 
> On Thursday 13 March 2008, Felipe Balbi wrote:
> > >   sched_clock:
> > >   16:     umull   r0, r1, r0, r3  @ tmp136, jiffies.371, tmp137
> > >
> > >   sched_slice:
> > >           ...
> > >   1243:   umull   r0, r1, r0, r2  @ slice.2262, slice,
> > > <variable>.load.weight

Thanks for digging into that.  I noticed it recently also on some builds.  

Maybe this umull comes from do_div() which has some inline assembly for this.  I recall that in used in sched_clock.  The inline asm might need a tweak.

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html