Hi Richard, Did you have a chance to look at updated patch?
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
