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.
