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)
