Message ID | BANLkTimBwRC43m_xqRrisGXSDjNW7jNiTg@mail.gmail.com |
---|---|
State | New |
Headers | show |
On Mon, Jun 20, 2011 at 12:23 PM, Kai Tietz <ktietz70@googlemail.com> wrote: > Hello, > > this patch adds to fold_binary_loc some missing optimization for binary > and operations on truth-not expressions. > Added cases are: > (!X & X) is always zero. > (X & !X) is always zero. > (X == 0) & X is always zero. > X & (X == 0) is always zero. > !X & 1 is X == 0 > > ChangeLog > > 2011-06-20 Kai Tietz <ktietz@redhat.com> > > * fold-const.c (fold_binary_loc): Add missing > folding for truth-not operations in combination > with binary and. > > ChangeLog > > 2011-06-20 Kai Tietz <ktietz@redhat.com> > > * gcc.dg/binop-notand1.c: New test. > * gcc.dg/binop-notand2.c: New test. > * gcc.dg/binop-notand3.c: New test. > * gcc.dg/binop-notand4.c: New test. > * gcc.dg/binop-notand5.c: New test. > * gcc.dg/binop-notand6.c: New test. > > Boostrapped and tested for x86_64-pc-linux-gnu. Ok for apply? Ok. Thanks, Richard. > Regards, > Kai >
2011/6/20 Richard Guenther <richard.guenther@gmail.com>: > On Mon, Jun 20, 2011 at 12:23 PM, Kai Tietz <ktietz70@googlemail.com> wrote: >> Hello, >> >> this patch adds to fold_binary_loc some missing optimization for binary >> and operations on truth-not expressions. >> Added cases are: >> (!X & X) is always zero. >> (X & !X) is always zero. >> (X == 0) & X is always zero. >> X & (X == 0) is always zero. >> !X & 1 is X == 0 >> >> ChangeLog >> >> 2011-06-20 Kai Tietz <ktietz@redhat.com> >> >> * fold-const.c (fold_binary_loc): Add missing >> folding for truth-not operations in combination >> with binary and. >> >> ChangeLog >> >> 2011-06-20 Kai Tietz <ktietz@redhat.com> >> >> * gcc.dg/binop-notand1.c: New test. >> * gcc.dg/binop-notand2.c: New test. >> * gcc.dg/binop-notand3.c: New test. >> * gcc.dg/binop-notand4.c: New test. >> * gcc.dg/binop-notand5.c: New test. >> * gcc.dg/binop-notand6.c: New test. >> >> Boostrapped and tested for x86_64-pc-linux-gnu. Ok for apply? > > Ok. > > Thanks, > Richard. > >> Regards, >> Kai Applied at revision 175206 to trunk. Thanks, Kai
On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote: > > Ok. > > Richard. > > Applied at revision 175206 to trunk. There is no need to post such notices to gcc-patches, we have the gcc-cvs mailing list where this is automatically posted to. On gcc-patches it just adds unnecessary noise. Jakub
On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote: >> > Ok. >> > Richard. >> >> Applied at revision 175206 to trunk. > > There is no need to post such notices to gcc-patches, we have the gcc-cvs > mailing list where this is automatically posted to. > On gcc-patches it just adds unnecessary noise. > > Jakub > Until there is some way to easily map an email on gcc-patches to an email on gcc-cvs, or a legitimate patch tracker instead of just mailing lists, then it is very useful "noise". I've found at least a hundred dropped patches so far for our project alone. You can always just delete the email instead of reading it.
On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote: > On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote: > >> Applied at revision 175206 to trunk. > > > > There is no need to post such notices to gcc-patches, we have the gcc-cvs > > mailing list where this is automatically posted to. > > On gcc-patches it just adds unnecessary noise. > > Until there is some way to easily map an email on gcc-patches to an > email on gcc-cvs, or a legitimate patch tracker instead of just > mailing lists, then it is very useful "noise". I've found at least a > hundred dropped patches so far for our project alone. You can always > just delete the email instead of reading it. No, our guidelines say that such mails shouldn't be sent: http://gcc.gnu.org/svnwrite.html "When you have checked in a patch exactly as it has been approved, you do not need to tell that to people -- including the approver. People interested in when a particular patch is committed can check SVN or the gcc-cvs list." This has been discussed several times. So no, this noise isn't at all useful nor welcome. Jakub
On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote: >> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> > On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote: >> >> Applied at revision 175206 to trunk. >> > >> > There is no need to post such notices to gcc-patches, we have the gcc-cvs >> > mailing list where this is automatically posted to. >> > On gcc-patches it just adds unnecessary noise. >> >> Until there is some way to easily map an email on gcc-patches to an >> email on gcc-cvs, or a legitimate patch tracker instead of just >> mailing lists, then it is very useful "noise". I've found at least a >> hundred dropped patches so far for our project alone. You can always >> just delete the email instead of reading it. > > No, our guidelines say that such mails shouldn't be sent: > > http://gcc.gnu.org/svnwrite.html > "When you have checked in a patch exactly as it has been approved, you do > not need to tell that to people -- including the approver. People > interested in when a particular patch is committed can check SVN or the > gcc-cvs list." "do not need" != "cannot" > > This has been discussed several times. So no, this noise isn't at all > useful nor welcome. useful or welcome.... TO YOU. Obviously, it's useful to us. > Jakub >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/20/11 09:34, NightStrike wrote: > On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote: >>> On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>>> On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote: >>>>> Applied at revision 175206 to trunk. >>>> >>>> There is no need to post such notices to gcc-patches, we have the gcc-cvs >>>> mailing list where this is automatically posted to. >>>> On gcc-patches it just adds unnecessary noise. >>> >>> Until there is some way to easily map an email on gcc-patches to an >>> email on gcc-cvs, or a legitimate patch tracker instead of just >>> mailing lists, then it is very useful "noise". I've found at least a >>> hundred dropped patches so far for our project alone. You can always >>> just delete the email instead of reading it. >> >> No, our guidelines say that such mails shouldn't be sent: >> >> http://gcc.gnu.org/svnwrite.html >> "When you have checked in a patch exactly as it has been approved, you do >> not need to tell that to people -- including the approver. People >> interested in when a particular patch is committed can check SVN or the >> gcc-cvs list." > > "do not need" != "cannot" > >> >> This has been discussed several times. So no, this noise isn't at all >> useful nor welcome. > > useful or welcome.... TO YOU. Obviously, it's useful to us. Umm, it's neither welcome nor useful to many folks -- that's why the guidelines are there. If you want commit acks, then extract them from the gcc-cvs list. They do not belong on gcc-patches. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN/2mHAAoJEBRtltQi2kC72HMH/AjsQQ4sZheMXP5rzRzrpWKG o6PnRDpTpo2ImjnfpSCUZdKgqBax9vRFRnR2mcrEnjZipVM4vIlRkQj93QVFfXTX 3KLTDdQX1+/1F+SADqAZ8ifGJWrdyArwWiB4qEvHmlYNbu2OjeJDxgeyE7WOYP5F R+wnQzJpsfwBcmi0o8+Wm8R9KtV6CEhgIyAES7A9LSLiFsc/YAVUlA7e2dPXDGOU kozUrQIUhPcg1NL9AMBFyDNLEDAP7sfdrxfe5+FOoGCj0yMvRR6D4ghrrvH2nUm/ fwCGOSUwHVexTHFlg0ZZTTabyjomLNq+ofjz+7VWgss8Or2+Wy/HcVR6z9T80ag= =POMm -----END PGP SIGNATURE-----
On Jun 20, 2011, at 8:38 AM, Jeff Law wrote: >> "do not need" != "cannot" >> >>> This has been discussed several times. So no, this noise isn't at all >>> useful nor welcome. >> >> useful or welcome.... TO YOU. Obviously, it's useful to us. > Umm, it's neither welcome nor useful to many folks -- that's why the > guidelines are there. > > They do not belong on gcc-patches. Agreed. svn log will tell you if a patch was committed and it is very reliable, unlike email.
Index: gcc/gcc/fold-const.c =================================================================== --- gcc.orig/gcc/fold-const.c 2011-06-20 10:45:33.000000000 +0200 +++ gcc/gcc/fold-const.c 2011-06-20 12:03:57.974484000 +0200 @@ -10866,13 +10866,19 @@ fold_binary_loc (location_t loc, if (operand_equal_p (arg0, arg1, 0)) return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0)); - /* ~X & X is always zero. */ - if (TREE_CODE (arg0) == BIT_NOT_EXPR + /* ~X & X, (X == 0) & X, and !X & X are always zero. */ + if ((TREE_CODE (arg0) == BIT_NOT_EXPR + || TREE_CODE (arg0) == TRUTH_NOT_EXPR + || (TREE_CODE (arg0) == EQ_EXPR + && integer_zerop (TREE_OPERAND (arg0, 1)))) && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)) return omit_one_operand_loc (loc, type, integer_zero_node, arg1); - /* X & ~X is always zero. */ - if (TREE_CODE (arg1) == BIT_NOT_EXPR + /* X & ~X , X & (X == 0), and X & !X are always zero. */ + if ((TREE_CODE (arg1) == BIT_NOT_EXPR + || TREE_CODE (arg1) == TRUTH_NOT_EXPR + || (TREE_CODE (arg1) == EQ_EXPR + && integer_zerop (TREE_OPERAND (arg1, 1)))) && operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0)) return omit_one_operand_loc (loc, type, integer_zero_node, arg0); @@ -10933,6 +10939,14 @@ fold_binary_loc (location_t loc, build_int_cst (TREE_TYPE (tem), 1)), build_int_cst (TREE_TYPE (tem), 0)); } + /* Fold !X & 1 as X == 0. */ + if (TREE_CODE (arg0) == TRUTH_NOT_EXPR + && integer_onep (arg1)) + { + tem = TREE_OPERAND (arg0, 0); + return fold_build2_loc (loc, EQ_EXPR, type, tem, + build_int_cst (TREE_TYPE (tem), 0)); + } /* Fold (X ^ Y) & Y as ~X & Y. */ if (TREE_CODE (arg0) == BIT_XOR_EXPR Index: gcc/gcc/testsuite/gcc.dg/binop-notand1.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc/gcc/testsuite/gcc.dg/binop-notand1.c 2011-06-20 11:02:49.718674700 +0200 @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int +foo (int a, int b) +{ + return (a & !a) | (b & !b); +} + +/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized" } } */ +/* { dg-final { cleanup-tree-dump "optimized" } } */ Index: gcc/gcc/testsuite/gcc.dg/binop-notand2.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc/gcc/testsuite/gcc.dg/binop-notand2.c 2011-06-20 11:31:36.415937400 +0200 @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int +foo (int a) +{ + return (!a & 1) != (a == 0); +} + +/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized" } } */ +/* { dg-final { cleanup-tree-dump "optimized" } } */ Index: gcc/gcc/testsuite/gcc.dg/binop-notand3.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc/gcc/testsuite/gcc.dg/binop-notand3.c 2011-06-20 11:33:55.974159000 +0200 @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int +foo (int a) +{ + return (!a & 1) != ((a == 0) & 1); +} + +/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized" } } */ +/* { dg-final { cleanup-tree-dump "optimized" } } */ Index: gcc/gcc/testsuite/gcc.dg/binop-notand4.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc/gcc/testsuite/gcc.dg/binop-notand4.c 2011-06-20 11:36:39.907475900 +0200 @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int +foo (int a, int b) +{ + return (!a & a) | (b & !b); +} + +/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized" } } */ +/* { dg-final { cleanup-tree-dump "optimized" } } */ Index: gcc/gcc/testsuite/gcc.dg/binop-notand5.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc/gcc/testsuite/gcc.dg/binop-notand5.c 2011-06-20 12:05:58.436280700 +0200 @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int +foo (int a, int b) +{ + return (a & (a == 0)) | (b & !b); +} + +/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized" } } */ +/* { dg-final { cleanup-tree-dump "optimized" } } */ Index: gcc/gcc/testsuite/gcc.dg/binop-notand6.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gcc/gcc/testsuite/gcc.dg/binop-notand6.c 2011-06-20 12:05:46.351746200 +0200 @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +int +foo (int a, int b) +{ + return (a & !a) | (b & (b == 0)); +} + +/* { dg-final { scan-tree-dump-times "return 0" 1 "optimized" } } */ +/* { dg-final { cleanup-tree-dump "optimized" } } */