[PATCH] Simple optimization for MASK_STORE.

Yuri Rumyantsev ysrumyan@gmail.com
Fri Nov 6 13:29:00 GMT 2015


Richard,

I tried it but 256-bit precision integer type is not yet supported.

Yuri.


2015-11-06 15:56 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
> On Mon, Nov 2, 2015 at 4:24 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
>> Hi Richard,
>>
>> I've come back to this optimization and try to implement your proposal
>> for comparison:
>>> Btw, you didn't try the simpler alternative of
>>>
>>> tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype)));
>>> build2 (EQ_EXPR, boolean_type_node,
>>>  build1 (VIEW_CONVERT, type, op0), build1 (VIEW_CONVERT, type, op1));
>>>
>>> ?  That is, use the GIMPLE level equivalent of
>>>  (cmp (subreg:TI reg:V4SI) (subreg:TI reg:V4SI))
>>
>> using the following code:
>>
>>       vectype = TREE_TYPE (mask);
>>       ext_mode = mode_for_size (GET_MODE_BITSIZE (TYPE_MODE (vectype)),
>> MODE_INT, 0);
>>       ext_type = lang_hooks.types.type_for_mode (ext_mode , 1);
>>
>> but I've got zero type for it. Should I miss something?
>
> Use ext_type = build_nonstandard_integer_type (GET_MODE_PRECISION
> (ext_mode), 1);
>
> Richard.
>
>> Any help will be appreciated.
>> Yuri.
>>
>>
>> 2015-08-13 14:40 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>> On Thu, Aug 13, 2015 at 1:32 PM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
>>>> Hi Richard,
>>>>
>>>> Did you have a chance to look at updated patch?
>>>
>>> Having a quick look now.  Btw, you didn't try the simpler alternative of
>>>
>>>  tree type = type_for_mode (int_mode_for_mode (TYPE_MODE (vectype)));
>>>  build2 (EQ_EXPR, boolean_type_node,
>>>    build1 (VIEW_CONVERT, type, op0), build1 (VIEW_CONVERT, type, op1));
>>>
>>> ?  That is, use the GIMPLE level equivalent of
>>>
>>>  (cmp (subreg:TI reg:V4SI) (subreg:TI reg:V4SI))
>>>
>>> ?  That should be supported by the expander already, though again not sure if
>>> the target(s) have compares that match this.
>>>
>>> Btw, the tree-cfg.c hook wasn't what was agreed on - the restriction
>>> on EQ/NE_EXPR
>>> is missing.  Operand type equality is tested anyway.
>>>
>>> Why do you need to restrict forward_propagate_into_comparison_1?
>>>
>>> Otherwise this looks better, but can you try with the VIEW_CONVERT as well?
>>>
>>> Thanks,
>>> Richard.
>>>
>>>
>>>> Thanks.
>>>> Yuri.
>>>>
>>>> 2015-08-06 14:07 GMT+03:00 Yuri Rumyantsev <ysrumyan@gmail.com>:
>>>>> HI All,
>>>>>
>>>>> Here is updated patch which implements Richard proposal to use vector
>>>>> comparison with boolean result instead of target hook. Support for it
>>>>> was added to ix86_expand_branch.
>>>>>
>>>>> Any comments will be appreciated.
>>>>>
>>>>> Bootstrap and regression testing did not show any new failures.
>>>>>
>>>>> ChangeLog:
>>>>> 2015-08-06  Yuri Rumyantsev  <ysrumyan@gmail.com>
>>>>>
>>>>> * config/i386/i386.c (ix86_expand_branch): Implement vector
>>>>> comparison with boolean result.
>>>>> * config/i386/sse.md (define_expand "cbranch<mode>4): Add define
>>>>> for vector comparion.
>>>>> * fold-const.c (fold_relational_const): Add handling of vector
>>>>> comparison with boolean result.
>>>>> * params.def (PARAM_ZERO_TEST_FOR_STORE_MASK): New DEFPARAM.
>>>>> * params.h (ENABLE_ZERO_TEST_FOR_STORE_MASK): new macros.
>>>>> * tree-cfg.c (verify_gimple_comparison): Add test for vector
>>>>> comparion with boolean result.
>>>>> * tree-ssa-forwprop.c (forward_propagate_into_comparison_1): Do not
>>>>> propagate vector comparion with boolean result.
>>>>> * tree-vect-stmts.c (vectorizable_mask_load_store): Initialize
>>>>> has_mask_store field of vect_info.
>>>>> * tree-vectorizer.c: Include files ssa.h, cfghooks.h and params.h.
>>>>> (is_valid_sink): New function.
>>>>> (optimize_mask_stores): New function.
>>>>> (vectorize_loops): Invoke optimaze_mask_stores for loops having masked
>>>>> stores.
>>>>> * tree-vectorizer.h (loop_vec_info): Add new has_mask_store field and
>>>>> correspondent macros.
>>>>>
>>>>> gcc/testsuite/ChangeLog:
>>>>> * gcc.target/i386/avx2-vect-mask-store-move1.c: New test.
>>>>>
>>>>>
>>>>> 2015-07-27 11:48 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>>>>> On Fri, Jul 24, 2015 at 9:11 PM, Jeff Law <law@redhat.com> wrote:
>>>>>>> On 07/24/2015 03:16 AM, Richard Biener wrote:
>>>>>>>>>
>>>>>>>>> Is there any rationale given anywhere for the transformation into
>>>>>>>>> conditional expressions?  ie, is there any reason why we can't have a
>>>>>>>>> GIMPLE_COND where the expression is a vector condition?
>>>>>>>>
>>>>>>>>
>>>>>>>> No rationale for equality compare which would have the semantic of
>>>>>>>> having all elements equal or not equal.  But you can't define a sensible
>>>>>>>> ordering (that HW implements) for other compare operators and you
>>>>>>>> obviously need a single boolean result, not a vector of element comparison
>>>>>>>> results.
>>>>>>>
>>>>>>> Right.  EQ/NE only as others just don't have any real meaning.
>>>>>>>
>>>>>>>
>>>>>>>> I've already replied that I'm fine allowing ==/!= whole-vector compares.
>>>>>>>> But one needs to check whether expansion does anything sensible
>>>>>>>> with them (either expand to integer subreg compares or add optabs
>>>>>>>> for the compares).
>>>>>>>
>>>>>>> Agreed, EQ/NE for whole vector compares only would be fine for me too under
>>>>>>> the same conditions.
>>>>>>
>>>>>> Btw, you can already do this on GIMPLE by doing
>>>>>>
>>>>>>   TImode vec_as_int = VIEW_CONVERT_EXPR <TImode> (vec_2);
>>>>>>   if (vec_as_int == 0)
>>>>>> ...
>>>>>>
>>>>>> which is what the RTL will look like in the end.  So not sure if making this
>>>>>> higher-level in GIMPLE is good or required.
>>>>>>
>>>>>> Richard.
>>>>>>
>>>>>>> jeff



More information about the Gcc-patches mailing list