From: Richard Henderson <r...@redhat.com>
Date: Fri, 30 Sep 2011 14:03:52 -0700
> On 09/30/2011 12:59 AM, David Miller wrote:
>>
>>[ VIS 2.0 bmask patterns ]
>
> I think this is wrong. I think you want to model this as
>
> [(set (match_operand:DI 0 "register_operand" "=r")
> (plus:DI (match_operand:DI 1 "register_or_zero_operand" "rJ")
> (match_operand:DI 2 "register_or_zero_operand" "rJ")))
> (set (zero_extract:DI
> (reg:DI GSR_REG)
> (const_int 32)
> (const_int 32))
> (plus:DI (match_dup 1) (match_dup 2)))]
Yep, perfect for 64-bit.
> (3) I realize this version makes things difficult for 32-bit mode.
> There, I think you may have to settle for an unspec. And perhaps
> the possible benefit of Properly representing the GSR change isn't
> that helpful. In which case:
>
> (set (reg:DI GSR_REG)
> (unspec:DI [(match_dup 1) (match_dup 2) (reg:DI GSR_REG)]
> UNSPEC_BMASK))
Actually, can't we just use a (zero_extend:DI (plus:SI ...)) for the
32-bit case? It seems to work fine.
>> +(define_insn "bshuffle<V64I:mode>_vis"
>> + [(set (match_operand:V64I 0 "register_operand" "=e")
>> + (unspec:V64I [(match_operand:V64I 1 "register_operand" "e")
>> + (match_operand:V64I 2 "register_operand" "e")]
>> + UNSPEC_BSHUFFLE))
>> + (use (reg:SI GSR_REG))]
>
> Better to push the use of the GSR_REG into the unspec, and not leave
> it separate in the parallel.
This is actually just a non-constant vec_merge, and even though the internals
documentation says that the 'items' operand has to be a const_int, the compiler
actually doesn't care.
The only two places vec_merge is even inspected semantically by the
compiler is in the RTX simplifier where it already checks explicitly
for const_int, and in dwarf2out.c where it just ignores the vec_merge
construct entirely since it can't be represented.
So if we just code this as:
(set (match_operand:V64I 0 "register_operand" "=e")
(vec_merge:V64I (match_operand:V64I 2 "register_operand" "e")
(match_operand:V64I 1 "register_operand" "e")
(zero_extract:DI (reg:DI GSR_REG)
(const_int 32)
(const_int 32))))
it would mostly work. The only problem with this is that we provide
the bshuffle builtin for DI mode just as we do for the faligndata
instruction. simplify-rtx.c isn't happy seeing a non-vector mode
and VECTOR_MODES () in a foo-modes.def file won't generate modes
like V1DI and V1SI.
I guess I could explicitly generate those single entry vector modes
like i386 does.
But, as-is, the above pattern does work for all the "actual" vector
modes.
More generally, rtl.def is non-specific about what operand 2 of a
vec_merge has to be, it just says a bitmask, it doesn't say that it
has to be a const_int.
I think we should explicitly allow non-const_int objects here, and state
so in the internals documentation.
