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
