v{extract,insert,broadcast,perm2}{i,f}128

[Jakub Jelinek]

On Tue, Sep 20, 2011 at 03:47:56PM +0200, Uros Bizjak wrote:
> No, you define mode attribute like
> 
> (define_mode_attr somesuffix [(V2DI "%i") (V2DF "f") ...])
> 
> where integer modes map to %i and FP modes to "f".
> 
> Then, just return "vextract<somesuffix>128\t{$0x1, %1, %0|%0, %1, 0x1}"

I can surely do that (or e.g.
(define_mode_attr i128 [(V4DI "%~128") (V4DF "f128") ...])
and
"vextract<i128>\t{$0x1, %1, %0|%0, %1, 0x1}"
)
if you prefer it that way, but that is a functional alternative
to the patch I've just posted.  What I don't know how to express
right now is that:
   (set (attr "mode")
     (if_then_else
       (and (match_test "TARGET_AVX2")
            (eq (const_string "<MODE>mode") (const_string "V4DImode")))
     (const_string "OI")
     (const_string "V4DF"))
I've used on some insns, i.e. for either all alternatives (or
just the ones that use <i128> insns), use MODE_OI if TARGET_AVX2
and MODE_VECTOR_INT, or MODE_V4DF resp. MODE_V8SF (what has been used
until now).  No idea whether something uses get_mode_attr for anything
scheduling related (or length etc.), or whether just lying that it is
MODE_V4DF or MODE_V8SF even for vector integer modes with TARGET_AVX2
is ok.

	Jakub