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?

Reply via email to