On Thu, Aug 13, 2015 at 1:32 PM, Yuri Rumyantsev <ysrum...@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 <ysrum...@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 <ysrum...@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.guent...@gmail.com>: >>> On Fri, Jul 24, 2015 at 9:11 PM, Jeff Law <l...@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
