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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-27
                 CC|                            |rguenth at gcc dot gnu.org
            Version|4.8.2                       |6.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.

I guess arm goes through the movmisalign optab for unaligned accesses and the
GIMPLE inlining could be enabled as well if movmisalign is supported.

Note that GCC 4.8 is no longer supported and enhancements will go to GCC 6 at
most.

With current trunk and -O2 -march=armv6 I get for

typedef unsigned int u32;
u32 read32(const void* ptr) { u32 v; __builtin_memcpy(&v, ptr, sizeof(v));
return v; }

read32:
        @ args = 0, pretend = 0, frame = 8
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        ldr     r0, [r0]        @ unaligned
        sub     sp, sp, #8
        add     sp, sp, #8
        @ sp needed
        bx      lr

so apart from the stack slot not getting removed this has already improved,
but the issue I mention still happens as we expand from

read32 (const void * ptr)
{
  u32 v;
  u32 _4;

  <bb 2>:
  __builtin_memcpy (&v, ptr_2(D), 4);
  _4 = v;
  v ={v} {CLOBBER};
  return _4;

so partially confirmed, for the GIMPLE memory op "inlining" issue.