Richard Biener <richard.guent...@gmail.com> writes: >>> I'm fine with using tree_nop_conversion_p for now. >> >> I like the suggestion about checking TYPE_VECTOR_SUBPARTS and the element >> mode. How about: >> >> (if (VECTOR_INTEGER_TYPE_P (type) >> && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)) >> && (TYPE_MODE (TREE_TYPE (type)) >> == TYPE_MODE (TREE_TYPE (TREE_TYPE (@0))))) >> >> (But is it really OK to be adding more mode-based compatibility checks? >> I thought you were hoping to move away from modes in the middle end.) > > The TYPE_MODE check makes the VECTOR_INTEGER_TYPE_P check redundant > (the type of a comparison is always a signed vector integer type).
OK, will just use VECTOR_TYPE_P then. >>>>> +/* We could instead convert all instances of the vec_cond to negate, >>>>> + but that isn't necessarily a win on its own. */ >>> >>> so p ? 1 : 0 -> -p? Why isn't that a win on its own? It looks more compact >>> at least ;) It would also simplify the patterns below. >> >> In the past I've dealt with processors where arithmetic wasn't handled >> as efficiently as logical ops. Seems like an especial risk for 64-bit >> elements, from a quick scan of the i386 scheduling models. > > But then expansion could undo this ... So do the inverse fold and convert (neg (cond)) to (vec_cond cond 1 0)? Is there precendent for doing that kind of thing? >> I also realised later that: >> >> /* Vector comparisons are defined to produce all-one or all-zero results. */ >> (simplify >> (vec_cond @0 integer_all_onesp@1 integer_zerop@2) >> (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) >> (convert @0))) >> >> is redundant with some fold-const.c code. > > If so then you should remove the fold-const.c at the time you add the pattern. Can I just drop that part of the patch instead? The fold-const.c code handles COND_EXPR and VEC_COND_EXPR analogously, so I'd have to move COND_EXPR at the same time. And then the natural follow-on would be: why not move the other COND_EXPR and VEC_COND_EXPR folds too? :-) > Note that ISTR code performing exactly the opposite transform in > fold-const.c ... That's another reason why I'm worried about just doing the (negate ...) thing without knowing whether the negate can be folded into anything else. Thanks, Richard
