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
