https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128422
Bug ID: 128422
Summary: Failure to use vector splat from GPR efficiently on
RISC-V
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Compile with -O3 -march=rv64gcbv_zicond:
typedef unsigned char __uint8_t;
typedef unsigned short int __uint16_t;
typedef unsigned int __uint32_t;
typedef __uint8_t uint8_t;
typedef __uint16_t uint16_t;
typedef __uint32_t uint32_t;
typedef union { uint32_t i; uint16_t b[2]; uint8_t c[4]; } x264_union32_t;
void predict_16x16_h( uint8_t *src )
{
for( int i = 0; i < 16; i++ )
{
const uint32_t v = 0x01010101 * src[-1];
(((x264_union32_t*)(src+ 0))->i) = v;
(((x264_union32_t*)(src+ 4))->i) = v;
(((x264_union32_t*)(src+ 8))->i) = v;
(((x264_union32_t*)(src+12))->i) = v;
src += 32;
}
}
Generates an insane blob of code. Wouldn't it be better to use a splatting
vector move to broadcast the value across the vector, then store the vector?