Re: [PATCH] Simple optimization for MASK_STORE.

[Yuri Rumyantsev <ysrumyan at gmail dot com>]

Hi Richard,

Did you have a chance to look at updated patch?

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