From: Eric Botcazou
Date: Mon, 24 Oct 2011 19:00:42 +0200
>> Great, committed to trunk.
>
> Minor nit: can't you uncouple the GY, ZC and DF couples of constraints now?
> We presumably need only one member of the couples per alternative now, i.e
> F,G,C in FP insns and D,Y,Z in vector insns.
Ri
> Great, committed to trunk.
Minor nit: can't you uncouple the GY, ZC and DF couples of constraints now?
We presumably need only one member of the couples per alternative now, i.e
F,G,C in FP insns and D,Y,Z in vector insns.
--
Eric Botcazou
From: Eric Botcazou
Date: Tue, 18 Oct 2011 00:57:18 +0200
>> I would suggest we start with my patch, get the int<-->float move
>> instructions working reasonably, and then re-add vector-only cases for
>> the scenerios you describe above, making sure that we don't end up with
>> silly code generat
> I would suggest we start with my patch, get the int<-->float move
> instructions working reasonably, and then re-add vector-only cases for
> the scenerios you describe above, making sure that we don't end up with
> silly code generation scenerios like those I've just described.
This sounds like
From: Eric Botcazou
Date: Tue, 18 Oct 2011 00:09:55 +0200
> I think that the original motivation for the previous design was the 32-bit
> vector ABI, where the arguments are passed in integer registers. So for:
>
> typedef char vec8 __attribute__((vector_size(8)));
>
> extern vec8 foo (vec8)
> This is an implementation of the changes I spoke about the other
> week. These changes segregate the vector vs. non-vector mode
> handling in the sparc backend.
I think that the original motivation for the previous design was the 32-bit
vector ABI, where the arguments are passed in integer reg
