[Bug target/109069] [12/13 Regression] Vector truncation test program produces incorrect result since r12-6537-g080a06fcb076b3

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109069

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Vector truncation test      |[12/13 Regression] Vector
                   |program produces incorrect  |truncation test program
                   |result on big-endian        |produces incorrect result
                   |powerpc64-linux-gnu with    |since
                   |-mcpu=power10 -O2           |r12-6537-g080a06fcb076b3
      Known to work|                            |11.3.0

--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
One test case can be:

#include <altivec.h>

__attribute__ ((noipa))
vector signed int
test ()
{
  vector signed int v = {-16, -16, -16, -16};
  vector signed int res = vec_sld (v, v, 3);
  return res;
}

int
main ()
{
  vector signed int res = test ();
  if (res[0] != 0xf0ffffff)
    __builtin_abort ();
  return 0;
}

It fails on Power7,8,9,10. It starts to fail from r12-6537-g080a06fcb076b3,
when the two input operands are the same, it's only safe to optimize it into a
vector move no matter what's the shift count is that the given vector is a
const vec_duplicate and the duplicated element is affordable in a byte. The
culprit commit is incorrect to use easy_vector_constant as predicate, which
just guards those vector constants without memory loading.

The reason why the reporter only saw this on Power10 is that the given constant
0xFA578D00u can only satisfy "easy_vector_constant" till power10. The
constructed test case above adopts one constant which can be built with
vspltisw, then we can easily see the failure.