Re: [PATCH, ARM] Low interrupt latency support (avoiding ldm/stm)

[Richard Earnshaw <rearnsha at arm dot com>]

On Fri, 2010-06-04 at 13:53 +0100, Julian Brown wrote:
> On Thu, 20 May 2010 13:19:45 +0100
> Julian Brown <julian@codesourcery.com> wrote:
> 
> > On Tue, 18 May 2010 11:49:17 +0100
> > Paul Brook <paul@codesourcery.com> wrote:
> > 
> > > > > It appears the feature I was thinking of[1] was only
> > > > > standardised in ARMv6, and may not be present on earlier cores.
> > > > > It's definitely present on arm11 and cortex-a8/r4/m3 based
> > > > > cores.
> > > > 
> > > > OK, so Paul, where does that leave us?  If Phil is right that this
> > > > is in fact pretty universal (and not unique to Marvell Feroceon
> > > > for which this patch was originally developed, IIRC), do you still
> > > > object to it going in?  (I have no opinion the name; if you prefer
> > > > -mavoid-ldm, that seems OK, though of course it also applies to
> > > > STM.)
> > > 
> > > I think the documentation needs improving. i.e. explain when it
> > > should be used and, more importantly, when it provides no benefit
> > > (Cortex-M[34], most armv6+ cores in low latency mode). Other than
> > > that it looks ok.  I don't care enough to argue about the name.
> > 
> > Here's a new version of the patch. I've renamed the option
> > "-mmultiple" for slight consistency with other targets and reversed
> > the sense (i.e. it is enabled by default, and you should use
> > "-mno-multiple" to turn off ldm/stm instructions). I've also improved
> > the documentation somewhat.
> > 
> > I'm not entirely sure still whether applying this patch is a good idea
> > though. There's a lot of potential for bit-rot to creep in (i.e.
> > introduction of ldm/stm or fldm/fstm instructions without checking the
> > use_load_store_multiple flag). OTOH I believe ARM's own compiler has
> > supported a similar option since prehistoric times, so maybe there's
> > demand.
> > 
> > Richard, what do you think?
> 
> Ping (Richard)?
> 
> Julian

I've no particular objection to this patch, but I can't help feeling
it's not really addressing the fundamental problem.

I think the problem we're really trying to fix is GCC's builtin
assumption about the mapping of vectors to registers (ie the order of
the lanes -- Joseph alludes to this in one of his posts on the thread)
and that fundamentally most of this is trying to paper over that
built-in assumption (it's a bit like trying to make big-endian look like
little-endian, or perhaps more accurately WORDS_BIG_ENDIAN+LITTLE_ENDIAN
look like a pure big or little-endian machine).

I haven't looked at the generic code, but my feeling is that what we
probably need to do is to break that assumption in the generic code (and
that until we do, we'll probably continue to run into corner cases that
break).  The way to do this is to have somethink like
VECTOR_LANES_BIG_ENDIAN as a target hook -- essentially, on ARM this
would always be false.

Can someone convince me I'm wrong?

R.