[Bug target/93932] New: PowerPC vec_extract with variable element number has code regressions for V2DI/V2DF vectors

[meissner at gcc dot gnu.org]

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

            Bug ID: 93932
           Summary: PowerPC vec_extract with variable element number has
                    code regressions for V2DI/V2DF vectors
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I've been looking at vec_extract recently, both in terms of support for the
-mcpu=future and to look at supporting PR target/93230 in GCC 11.

In some cases, if you have a vec_extract built-in function where the vector is
in a register, and the element is variable, the compiler decides store this
vector to memory, and then do the variable extract using a scalar load. 
Unfortunately, this lead to a STORE-HIT-LOAD slowdown, as the scalar load will
likely have to wait for the vector store to finish.

The test cases are the fold-vect-extract-<type>.p{7,8,9}.c} files in the
gcc.target/powerpc directory, where <type> is 'char', 'short', 'int',
'longlong', 'float' and 'double', and the p7/p8/p9 indicates whether the test
is for -mcpu=power7, -mcpu=power8, or -mcpu=power9.

For -mcpu=power8, the regressions are:
fold-vect-extract-double.p8.c: GCC 9.x and current trunk
fold-vect-extract-longlong.p8.c: GCC 9.x and current trunk

For -mcpu=power9, the regressions are:
fold-vect-extract-double.p9.c: GCC 9.x (current trunk is ok)
fold-vect-extract-longlong.p9.c: GCC 9.x (current trunk is ok)