https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #21 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- 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.