https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to jos...@codesourcery.com from comment #4)
> Any unaligned access things that don't work for big-endian ARM are
> probably fallout from the issues with big-endian NEON (NEON architectural
> lane numbers are different from the architecture-independent lane numbers
> in GNU C vector extensions and GCC IR, and GCC expects each machine mode
> to have a single defined memory layout and a single defined layout in any
> given register, and to be able to move between core and NEON registers,
> and between core registers and memory, in the respective layouts used for
> those registers, but some NEON loads and stores for big-endian don't work
> with those expectations, so unaligned vector operations are limited for
> big-endian ARM).
Correct, we don't allow misaligned access for Neon because of exactly the above
mentioned reasons.
I would have however expected misaligned access to work with -march=armv7-a
-munaligned-access -mfpu=vfpv3-d16 -mfloat-abi=softfp/hard on the command line
for the afore mentioned testcase as we do have a movmisalign pattern in arm.md
that should kick in overriding the movmisalign pattern in neon.md. It probably
needs a little more detailed investigation.
