[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

["rearnsha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.