On Fri, Jun 26, 2015 at 12:39 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Wed, 24 Jun 2015, Richard Biener wrote: > >> On Wed, Jun 24, 2015 at 11:57 AM, Richard Sandiford >> <richard.sandif...@arm.com> wrote: >>> >>> Richard Biener <richard.guent...@gmail.com> writes: >>>> >>>> On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse <marc.gli...@inria.fr> >>>> wrote: >>>>> >>>>> On Tue, 23 Jun 2015, Richard Sandiford wrote: >>>>> >>>>>> +/* 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))) >>>>> >>>>> >>>>> >>>>> I am trying to understand why the test tree_nop_conversion_p is the >>>>> right >>>>> one (at least for the transformations not using VIEW_CONVERT_EXPR). By >>>>> definition of VEC_COND_EXPR, type and TREE_TYPE (@0) are both integer >>>>> vector >>>>> types of the same size and number of elements. It thus seems like a >>>>> conversion is always fine. For vectors, tree_nop_conversion_p >>>>> apparently >>>>> only checks that they have the same mode (quite often VOIDmode I >>>>> guess). >>>> >>>> >>>> The only conversion we seem to allow is changing the signed vector from >>>> the comparison result to an unsigned vector (same number of elements >>>> and same mode of the elements). That is, a check using >>>> TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (@0)) would probably >>>> be better (well, technically a TYPE_VECTOR_SUBPARTS && element >>>> mode compare should be better as generic vectors might not have a vector >>>> mode). >>> >>> >>> OK. The reason I was being paranoid was that I couldn't see anywhere >>> where we enforced that the vector condition in a VEC_COND had to have >>> the same element width as the values being selected. >> >> >> We don't require that indeed. >> >>> tree-cfg.c >>> only checks that rhs2 and rhs3 are compatible with the result. >>> There doesn't seem to be any checking of rhs1 vs. the other types. >>> So I wasn't sure whether anything stopped us from, e.g., comparing two >>> V4HIs and using the result to select between two V4SIs. >> >> >> Nothing does (or should). > > > The documentation patch you approved in > https://gcc.gnu.org/ml/gcc-patches/2012-10/msg01109.html says something > different. If it is really wrong, could you fix it?
Hmm, that simplifies things. It would be nice if these constraints would also be checked in the gimple verifier... Richard. > -- > Marc Glisse
