Vectorizer generates unaligned access when -mno-unaligned-access is enabled

[Yury Gribov]

I have recently ran into a problem after trying to simultaneously enable
both -mno-unaligned-access and -ftree-vectorize in gcc-linaro-2013.12:

 $ arm-v7a15v5r0-linux-gnueabi-gcc -mcpu=cortex-a15 -mcpu=cortex-a15 -mfloat-abi=softfp -mfpu=neon -ffast-math -ftree-vectorize -fno-common -O2 -mno-unaligned-access repro.c
 $ scp a.out root@myboard:/

and then on target board:

 # /a.out
 Bus error

The error is caused by unaligned vector load via two vldr instructions:

 $ cat repro.s
 ...
.L3:
 vldr d16, [r3, #-16]
 vldr d17, [r3, #-8]
 ...

After some investigation I found possible source of this bug in ARM backend.
It looks that even if -mno-unaligned-access is enabled, backend will inform
vectorizer that it supports misaligned accesses
via TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT hook which
expands to arm_builtin_support_vector_misalignment.

At the same time backend will disable RTL patterns to handle misaligned
acceses in neon.md:
(define_expand "movmisalign<mode>"
  ...
  "TARGET_NEON && !BYTES_BIG_ENDIAN && unaligned_access"
(note the "&& unaligned_access" part).

This will force vectorizer to generated an unaligned vector load
which will be handled by standard "neon_mov<mode>" pattern.
This pattern will generate erroneous vldr instructions (in output_move_neon).

The relevant code (arm_builtin_support_vector_misalignment and misalign patterns)
has not changed in 4.9 so it probably makes sense to fix this directly in 4.9.

[Yury Gribov (tetra2005)]

Re-attaching patch in unified diff format.

[Kugan Vivekanandarajah (kugan-vivekanandarajah)]

I can reproduce this with an older version of trunk. It seems to have gone latent in the current version, though the problem is still there. Working on a patch for this.

[Yury Gribov (tetra2005)]

Kugan,

Are there updates on this? Do you think the attached patch makes sense?

-Y

[Kugan Vivekanandarajah (kugan-vivekanandarajah)]

Thanks Yury for the patch. Your fix makes sense and I have posted the patch to gcc list after testing it. Please see the link:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00048.html