Re: [PATCH 5/6] mips: Implement vec_perm_const.

[Richard Sandiford <rdsandiford at googlemail dot com>]

Richard Henderson <rth@redhat.com> writes:
> On 12/11/2011 04:50 AM, Richard Sandiford wrote:
>> [Mingjie, please could you help with the Loongson question near the end?]
>
> Actually, can you tell me how to test these abi combinations?  I keep
> trying to use mips-sim or mips64-sim and get linker errors complaining
> of abi combinations.

I tend to use mips64{,el}-linux-gnu with a hacked-up QEMU (hacked up to
add MIPS16 to the cpu model, which isn't relevant here).  But I'm surprised
*-elf is causing problems.  Something like mipsisa64-elfoabi ought to just
work (I last tested that a few weeks ago).

>>      Little-endian:
>> 
>>         The semantics of the RTL pattern are:
>> 
>> 	{ 0L, 0U } = { X[I3], X[I4 + 2] }, where X = { 1L, 1U, 2L, 2U }
>> 
>> 	so: 0L = { 1L, 1U }[I3] (= <bop><bUL>)
>> 	    0U = { 2L, 2U }[I4] (= <aop><aUL>)
>> 
>> 	    <aop> = 2, <aUL> = I4 ? U : L
>> 	    <bop> = 1, <bUL> = I3 ? U : L
>> 
>> 	    [LL] !I4 && !I3   [UL] I4 && !I3
>> 	    [LU] !I4 && I3    [UU] I4 && I3
>> 
>>      Big-endian:
>> 
>>         The semantics of the RTL pattern are:
>> 
>> 	{ 0U, 0L } = { X[I3], X[I4 + 2] }, where X = { 1U, 1L, 2U, 2L }
>> 
>> 	so: 0U = { 1U, 1L }[I3] (= <aop><aUL>)
>> 	    0L = { 2U, 2L }[I4] (= <bop><bUL>)
>> 
>> 	    <aop> = 1, <aUL> = I3 ? L : U
>> 	    <bop> = 2, <bUL> = I4 ? L : U
>> 
>> 	    [UU] !I3 && !I4   [UL] !I3 && I4
>> 	    [LU] I3 && !I4    [LL] I3 && I4.  */
>> 
>> which suggests that the PUL and PLU entries for big-endian should be
>> the other way around.  Does that sound right, or have I misunderstood?
>
> Yes, that sounds right.
>
>> ...for little-endian, we need to pass the "U" and "L" components of the
>> mnemonic in the reverse order: the MIPS instruction specifies the upper
>> part first, whereas the rtl pattern specifies the lower part first.
>> And for little-endian, U refers to memory element 1 and L to memory
>> element 0.  So I think this should be:
>
> ... Except that the actual output of the LE insn actually swaps the
> operands too.  So I think these expanders should not *also* swap the
> operands.  I've tidied these up a bit since then.

Hmm, are you sure?  The order of the operands passed to these p?? expanders
is supposed to match the order of the operands in the final asm instruction.
A user's "A = __builtin_mips_plu_ps (B, C)" corresponds to
"gen_mips_plu_ps (A, B, C)", which must always generate "PLU.PS A, B, C", etc.
So if the define_insn swaps the operands (which from above, it must for
little-endian), then these expanders need to swap too, to undo the effect.
Or, taking the longer version from yesterday:

;; Expanders for builtins.  The instruction:
;;
;;     P[UL][UL].PS <result>, <a>, <b>
;;
;; says that the upper part of <result> is taken from half of <a> and
;; the lower part of <result> is taken from half of <b>.  This means
;; that the P[UL][UL].PS operand order matches memory order on big-endian
;; targets; <a> is element 0 of the V2SF result while <b> is element 1.
;; However, the P[UL][UL].PS operand order is the reverse of memory order
;; on little-endian targets; <a> is element 1 of the V2SF result while
;; <b> is element 0.  The arguments to vec_perm_const_ps are always in
;; memory order.
;;
;; Similarly, "U" corresponds to element 0 on big-endian targets but
;; to element 1 on little-endian targets.

(would be nice to have these comments in the patch if nothing else).

Because of that, I think I preferred the original style, with no
SET rtl pattern in the expander, and calls to emit_insn (gen_...)
in the C code.

>> I think this is endian-dependent.  For little-endian, the bottom two bits
>> of the mask determine element 0; for big-endian, the top two bits of the
>> mask do. 
>
> Recall that loongson can only run in little-endian.

Doh.

> I added comments about that in the md file, but it would do no harm to
> add another here.

Thanks.

Richard