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

[Richard Earnshaw <rearnsha at arm dot com>]

Sorry, that was in reply to a completely different thread.  Let me
backtrack and re-post...

R.

On Fri, 2010-06-04 at 17:16 +0100, Richard Earnshaw wrote:
> 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.