simd: Small win but terrible code!

[Ian Dall]

Ian Dall <ian@beware.dropbear.id.au> writes:

> I think I have found a problem in reload.c:find_valid_class(), which
> only shows up for small register classes.
> 
> [...]
> I think inserting and extra test:
> 
>       if (reg_class_size[class] < (n + 1))
> 	continue;
> 
> solves the problem.

With this patch, and fixing another problem in the ns32k port
using CANNOT_CHANGE_MODE_CLASS, I fix a ICE on the simd-3.c test. This
counts as a small win. This port has no vector instructions.

However, the generated code is terrible!
As far as I can see, the vector version:


    void tempf(double *x, double *y)
    {
            floatvect2 temp={x[0],x[1]};
            floatvect2 temp1={y[0],y[1]};
            resfloatvect2 temp2;
            temp2.vector=temp+temp1;
            x[0]=temp2.f[0];
            x[1]=temp2.f[1];
    }

is functionally the same as the following, if you eliminate the intermediate
variables and type punning:

    void tempa(double *x, double *y)
    {
      x[0] = x[0] + y[0];
      x[1] = x[1] + y[1];
    }

The former takes 39 instructions, dirties all the gerneral registers
and transfers 57 words to or from memory, not counting the registers
saved and restored in the prolog! The latter uses 4 instructions and
transfers 14 words to or from memory and doesn't dirty any registers
beyond the scratch (caller save) registers.

This appears to be because expand_vector_binop insists on extracting
SImode subregs (which then have to be re-assembled into DFmode operands).
The optimization passes are evidently unable to discover and remove this
useless shuffling. So, why do we use extract_bit_field on the operands?

Ian