| Message ID | CAAgBjMkLnZ8WSuQ_oE5zo2CG-zUJZcgVt3HqztGqxz+Yv+BCOg@mail.gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, 4 Nov 2016, Prathamesh Kulkarni wrote: > On 4 November 2016 at 13:41, Richard Biener <rguenther@suse.de> wrote: > > On Thu, 3 Nov 2016, Marc Glisse wrote: > > > >> On Thu, 3 Nov 2016, Richard Biener wrote: > >> > >> > > > > 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. > >> > >> Oups, that's what I had written first, and then I somehow managed to confuse > >> myself enough to remove it so as to remove the call to types_match :-( > >> > >> > > 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. > >> > >> Oh, right, I keep forgetting that :-( And I have no idea how to generate one > >> for a testcase, at least until the GIMPLE FE lands... > >> > >> > > 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. > >> > >> Would that generate sensible code on targets that do not have logic insns for > >> floats? Actually, even on x86_64 that generates inefficient code, so there > >> would be some work (for instance grep finds no gen_iordf3, only gen_iorv2df3). > >> > >> I am also a bit wary of doing those obfuscating optimizations too early... > >> a==0 is something that other optimizations might use. long > >> c=(long&)a|(long&)b; (double&)c==0; less so... > >> > >> (and I am assuming that signaling NaNs don't make the whole transformation > >> impossible, which might be wrong) > > > > Yeah. I also think it's not so much important - I just wanted to mention > > vectors... > > > > Btw, I still think we need a more sensible infrastructure for passes > > to gather, analyze and modify complex conditions. (I'm always pointing > > to tree-affine.c as an, albeit not very good, example for handling > > a similar problem) > Thanks for mentioning the value-matching capture @@, I wasn't aware of > this match.pd feature. > The current patch keeps it restricted to only bitwise operators on integers. > Bootstrap+test running on x86_64-unknown-linux-gnu. > OK to commit if passes ? +/* PR35691: Transform + (x == 0 & y == 0) -> (x | typeof(x)(y)) == 0. + (x != 0 | y != 0) -> (x | typeof(x)(y)) != 0. */ + Please omit the vertical space +(for bitop (bit_and bit_ior) + cmp (eq ne) + (simplify + (bitop (cmp @0 integer_zerop) (cmp @1 integer_zerop)) if you capture the first integer_zerop as @2 then you can re-use it... + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) + && INTEGRAL_TYPE_P (TREE_TYPE (@1)) + && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))) + (cmp (bit_ior @0 (convert @1)) { build_zero_cst (TREE_TYPE (@0)); ... here inplace of the { build_zero_cst ... }. Ok with that changes. Richard.
diff --git a/gcc/match.pd b/gcc/match.pd index 48f7351..4f74942 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -519,6 +519,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (if (TYPE_UNSIGNED (type)) (bit_and @0 (bit_not (lshift { build_all_ones_cst (type); } @1))))) +/* PR35691: Transform + (x == 0 & y == 0) -> (x | typeof(x)(y)) == 0. + (x != 0 | y != 0) -> (x | typeof(x)(y)) != 0. */ + +(for bitop (bit_and bit_ior) + cmp (eq ne) + (simplify + (bitop (cmp @0 integer_zerop) (cmp @1 integer_zerop)) + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) + && INTEGRAL_TYPE_P (TREE_TYPE (@1)) + && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))) + (cmp (bit_ior @0 (convert @1)) { build_zero_cst (TREE_TYPE (@0)); })))) + /* Fold (A & ~B) - (A & B) into (A ^ B) - B. */ (simplify (minus (bit_and:cs @0 (bit_not @1)) (bit_and:cs @0 @1)) diff --git a/gcc/testsuite/gcc.dg/pr35691-1.c b/gcc/testsuite/gcc.dg/pr35691-1.c new file mode 100644 index 0000000..5211f815 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr35691-1.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-forwprop-details" } */ + +int foo(int z0, unsigned z1) +{ + int t0 = (z0 == 0); + int t1 = (z1 == 0); + int t2 = (t0 && t1); + return t2; +} + +/* { dg-final { scan-tree-dump "gimple_simplified to _\[0-9\]* = \\(int\\) z1_\[0-9\]*\\(D\\);" "forwprop1" } } */ diff --git a/gcc/testsuite/gcc.dg/pr35691-2.c b/gcc/testsuite/gcc.dg/pr35691-2.c new file mode 100644 index 0000000..90cbf6d --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr35691-2.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-forwprop-details" } */ + +int foo(int z0, unsigned z1) +{ + int t0 = (z0 != 0); + int t1 = (z1 != 0); + int t2 = (t0 || t1); + return t2; +} + +/* { dg-final { scan-tree-dump "gimple_simplified to _\[0-9\]* = \\(int\\) z1_\[0-9\]*\\(D\\);" "forwprop1" } } */