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

[David Brownell <david-b@pacbell.net>]

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