https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with
>
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee -marm -mlibarch=armv7-a+neon-vfpv4
> -march=armv7-a+neon-vfpv4 -O2 -fPIE -fvisibility=hidden
> -fvisibility-inlines-hidden -fmerge-all-constants -fmath-errno
> -fno-exceptions
>
> The critical sequence, at the end of gimple optimization is:
>
> v = b;
> MEM <unsigned char[16]> [(char * {ref-all})&D.33805] = MEM <unsigned
> char[16]> [(char * {ref-all})&v];
> v ={v} {CLOBBER(eol)};
> v = D.33805;
> vect__239.652_700 = MEM <vector(8) short int> [(short int *)&v];
> vect__240.653_702 = vect__239.652_700 << 8;
>
> This generates the following (pseudo) rtl:
>
> ; D.33805 = _179
> 113: r215:SI=r109:SI-0x10
> 114: {r0:SI..r3:SI} = [r215:SI (0 MEM <unsigned char[16]> [(char *
> {ref-all})_179]+0 S4 A64)]
> 112: r214:SI=r109:SI-0x60
> 115: [r214:SI (0 MEM <unsigned char[16]> [(char * {ref-all})&D.33805]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
> 117: r217:SI=r109:SI-0x60
> 118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
> 116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128<short int, 8> *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM <vector(8) short int> [(short int
> *)_179]+0 S16 A64)]
> 121: r178:V8HI=unspec[r218:V8HI,const_vector] 451
>
> The two key instructions have been starred.
>
> Things proceed OK until sched2, at which point, when building the
> dependencies, we fail to create a link between i119 and i120. I've tracked
> this as far as ptr_deref_may_alias_decl_p (), where the call to
> may_be_aliased () decides that D.33805 cannot be aliased and thus there's no
> dependency. But it's not clear to me why we've tracked back to the copy
> before the load of interest, nor why, at this point, we're looking at tree
> addressability to decide whether or not there are memory dependencies here.
This making it sound like one of the -fstack-reuse= issues (see the linked bug
reports from PR 111843). Does -fstack-reuse=none help?
