On Tue, Sep 20, 2011 at 4:07 PM, Uros Bizjak <ubiz...@gmail.com> 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.
Oh, and you can use <sseinsnmode> to set mode attribute statically.
Uros.
