On November 3, 2016 6:11:07 PM GMT+01:00, Marc Glisse <marc.gli...@inria.fr> wrote: >On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote: > >> On 3 November 2016 at 16:13, Richard Biener <rguent...@suse.de> >wrote: >>> On Thu, 3 Nov 2016, Prathamesh Kulkarni wrote: >>> >>>> Hi Richard, >>>> The attached patch tries to fix PR35691, by adding the following >two >>>> transforms to match.pd: >>>> (x == 0 && y == 0) -> (x | typeof(x)(y)) == 0. >>>> (x != 0 || y != 0) -> (x | typeof(x)(y)) != 0. >>>> >>>> For GENERIC, the "and" operator is truth_andif_expr, and it seems >for GIMPLE, >>>> it gets transformed to bit_and_expr >>>> so to match for both GENERIC and GIMPLE, I had to guard the >for-stmt: >>>> >>>> #if GENERIC >>>> (for op (truth_andif truth_orif) >>>> #elif GIMPLE >>>> (for op (bit_and bit_ior) >>>> #endif >>>> >>>> Is that OK ? >>> >>> As you are not removing the fold-const.c variant I'd say you should >>> simply not look for truth_* and only handle GIMPLE. Note that we >>> have tree-ssa-ifcombine.c which should handle the variant with >>> control-flow (but I guess it does not and your patch wouldn't help >>> it either). >>> >>> The transform would also work for vectors (element_precision for >>> the test but also a value-matching zero which should ensure the >>> same number of elements). >> Um sorry, I didn't get how to check vectors to be of equal length by >a >> matching zero. >> Could you please elaborate on that ? > >He may have meant something like: > > (op (cmp @0 integer_zerop@2) (cmp @1 @2))
I meant with one being @@2 to allow signed vs. Unsigned @0/@1 which was the point of the pattern. >So the last operand is checked with operand_equal_p instead of >integer_zerop. But the fact that we could compute bit_ior on the >comparison results should already imply that the number of elements is >the >same. Though for equality compares we also allow scalar results IIRC. This would also prevent the case where one vector is signed and >the >other unsigned, which requires a view_convert (I don't remember if >convert >automatically becomes view_convert here as in fold_convert or not). No, but the other way around (for sign changes). >For (some_int == 0) & (some_long == 0), doing ((long)some_int | >some_long) >== 0 should also work (and it doesn't matter if we pick a sign- or >zero-extension), but that's more complicated, not necessary for a first > >version. Yeah. >On platforms that have IOR on floats (at least x86 with SSE, maybe some > >vector mode on s390?), it would be cool to do the same for floats (most > >likely at the RTL level). On GIMPLE view-converts could come to the rescue here as well. Or we cab just allow bit-and/or on floats as much as we allow them on pointers. Richard.
