[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus

["ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366

--- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #3)
> On Thu, 27 Aug 2015, rearnsha at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366
> > 
> > --- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
> > (In reply to Richard Biener from comment #1)
> > > I think this boils down to the fact that memcpy expansion is done too late
> > > and
> > > that (with more recent GCC) the "inlining" done on the GIMPLE level is
> > > restricted
> > > to !SLOW_UNALIGNED_ACCESS but arm defines STRICT_ALIGNMENT to 1
> > > unconditionally.
> > > 
> > 
> > Yep, we have to define STRICT_ALIGNMENT to 1 because not all load instructions
> > work with misaligned addresses (ldm, for example).  The only way to handle
> > misaligned copies is through the movmisalign API.
> 
> Are the movmisalign handled ones reasonably efficient?  That is, more
> efficient than memcpy/memmove?  Then we should experiment with
> 
> Index: gcc/gimple-fold.c
> ===================================================================
> --- gcc/gimple-fold.c   (revision 227252)
> +++ gcc/gimple-fold.c   (working copy)
> @@ -708,7 +708,9 @@ gimple_fold_builtin_memory_op (gimple_st
>                   /* If the destination pointer is not aligned we must be 
> able
>                      to emit an unaligned store.  */
>                   && (dest_align >= GET_MODE_ALIGNMENT (TYPE_MODE (type))
> -                     || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
> dest_align)))
> +                     || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), 
> dest_align)
> +                     || (optab_handler (movmisalign_optab, TYPE_MODE 
> (type))
> +                         != CODE_FOR_nothing)))
>                 {
>                   tree srctype = type;
>                   tree desttype = type;
> @@ -720,7 +722,10 @@ gimple_fold_builtin_memory_op (gimple_st
>                     srcmem = tem;
>                   else if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE 
> (type))
>                            && SLOW_UNALIGNED_ACCESS (TYPE_MODE (type),
> -                                                    src_align))
> +                                                    src_align)
> +                          && (optab_handler (movmisalign_optab,
> +                                             TYPE_MODE (type))
> +                              == CODE_FOR_nothing))
>                     srcmem = NULL_TREE;
>                   if (srcmem)
>                     {

This plus the backend changes to deal with unaligned himode and simode values
tested ok on armhf with only 2 extra failures in strlen-opt-8.c. Prima-facie
they appear to be testisms, but it will be fun to handle this across all
architecture levels for the arm target as unaligned access depends on
architecture levels.