Re: [PATCH, ARM] Misaligned access support for ARM Neon

[Richard Earnshaw <rearnsha at arm dot com>]

On Mon, 2009-11-30 at 14:28 +0000, Paul Brook wrote:
> On Monday 30 November 2009, Richard Earnshaw wrote:
> > On Mon, 2009-11-30 at 14:01 +0000, Joseph S. Myers wrote:
> > > On Mon, 30 Nov 2009, Julian Brown wrote:
> > > > I've also drafted a bit of hopefully-explanatory text in md.texi about
> > > > movmisalign<mode> and element ordering.
> > >
> > > Texinfo markup fixes: ``opaque'', @code{TARGET_VECTOR_ALWAYS_MISALIGN}.
> > > The two new target hooks TARGET_VECTOR_ALWAYS_MISALIGN and
> > > TARGET_VECTOR_MIN_ALIGNMENT also need documentation in tm.texi.
> > 
> > I can't say I like this particular way of describing Neon.  It seems to
> > me that what's really needed is for the vectorizer to have an equivalent
> > concept for vector elements to the TARGET_WORDS_BIG_ENDIAN -- namely
> > TARGET_VECT_ELEMENTS_BIG_ENDIAN -- on Neon this would always be false.
> 
> Are you saying you think the vectorizer should be using vldr, not vld1?
> Or that you don't like this particular way of distinguishing between array 
> loads and vector copies?
> Or that we also need to fix whichever bits of the autovectorizer that know 
> about vector layout and remove the BYTES_BIG_ENDIAN hack in 
> arm_vector_always_misalign?

I certainly think we shouldn't be hiding knowledge about the element to
vector-lane mapping from the vectorizer -- and that the vectorizer
should understand that vector copies are not necessarily the same as
vectorizing loads.  Anything else and we will ultimately have parts of
the compiler fighting against each other and that way lies subtle bugs.

R.