On Tue, Sep 20, 2011 at 4:00 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> 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.
mode attribute us used only to calculate various prefixes (and that
should be reviewed anyway). But for modes you are referring to, it
doesn't matter that much.
Uros.
