From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94590 invoked by alias); 20 Sep 2018 14:01:16 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 62319 invoked by uid 89); 20 Sep 2018 14:00:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy= X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Sep 2018 14:00:29 +0000 Received: from nat-eduroam-138-gw-01-sif.saclay.inria.fr (HELO 201-135.eduroam.saclay.inria.fr) ([195.83.213.138]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2018 16:00:22 +0200 Date: Thu, 20 Sep 2018 14:04:00 -0000 From: Marc Glisse Reply-To: gcc-patches@gcc.gnu.org To: Richard Biener cc: mcccs@gmx.com, GCC Patches Subject: Re: Fold more boolean expressions In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2018-09/txt/msg01142.txt.bz2 On Thu, 20 Sep 2018, Richard Biener wrote: > On Sat, Sep 15, 2018 at 8:01 AM MCC CS wrote: >> >> Sorry for doing the same mistake twice. Is this OK, and do >> I need to test it again after the first version of this >> patch? >> >> 2018-09-15 MCC CS >> >> gcc/ >> PR tree-optimization/87261 >> * match.pd: Add boolean optimizations, >> fix whitespace. >> >> 2018-09-15 MCC CS >> >> gcc/testsuite/ >> PR tree-optimization/87261 >> * gcc.dg/pr87261.c: New test. >> >> Index: gcc/match.pd >> =================================================================== >> --- gcc/match.pd (revision 264170) >> +++ gcc/match.pd (working copy) >> @@ -92,7 +92,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >> IFN_FMA IFN_FMS IFN_FNMA IFN_FNMS) >> (define_operator_list COND_TERNARY >> IFN_COND_FMA IFN_COND_FMS IFN_COND_FNMA IFN_COND_FNMS) >> - >> + >> /* As opposed to convert?, this still creates a single pattern, so >> it is not a suitable replacement for convert? in all cases. */ >> (match (nop_convert @0) >> @@ -106,7 +106,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >> && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE (@0)))))) >> /* This one has to be last, or it shadows the others. */ >> (match (nop_convert @0) >> - @0) >> + @0) >> >> /* Transform likes of (char) ABS_EXPR <(int) x> into (char) ABSU_EXPR >> ABSU_EXPR returns unsigned absolute value of the operand and the operand >> @@ -285,7 +285,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >> And not for _Fract types where we can't build 1. */ >> (if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type))) >> { build_one_cst (type); })) >> - /* X / abs (X) is X < 0 ? -1 : 1. */ >> + /* X / abs (X) is X < 0 ? -1 : 1. */ >> (simplify >> (div:C @0 (abs @0)) >> (if (INTEGRAL_TYPE_P (type) >> @@ -921,6 +921,31 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >> (bitop:c @0 (bit_not (bitop:cs @0 @1))) >> (bitop @0 (bit_not @1)))) >> >> +/* (~x & y) | ~(x | y) -> ~x */ >> +(simplify >> + (bit_ior:c (bit_and:c (bit_not@2 @0) @1) (bit_not (bit_ior:c @0 @1))) >> + @2) >> + >> +/* (x | y) ^ (x | ~y) -> ~x */ >> +(simplify >> + (bit_xor:c (bit_ior:c @0 @1) (bit_ior:c @0 (bit_not @1))) >> + (bit_not @0)) >> + >> +/* (x & y) | ~(x | y) -> ~(x ^ y) */ >> +(simplify >> + (bit_ior:c (bit_and @0 @1) (bit_not:s (bit_ior:s @0 @1))) > > I think this misses :cs on the bit_and. For :c, shouldn't canonicalization make the order of @0 and @1 consistent for bit_and and bit_ior? >> + (bit_not (bit_xor @0 @1))) >> + >> +/* (~x | y) ^ (x ^ y) -> x | ~y */ >> +(simplify >> + (bit_xor:c (bit_ior:cs (bit_not @0) @1) (bit_xor:c @0 @1)) >> + (bit_ior @0 (bit_not @1))) > > :s on the bit_xor > >> +/* (x ^ y) | ~(x | y) -> ~(x & y) */ >> +(simplify >> + (bit_ior:c (bit_xor @0 @1) (bit_not:s (bit_ior @0 @1))) >> + (bit_not (bit_and @0 @1))) > > :cs on the bit_xor, :s on the second bit_ior > > Otherwise looks OK to me. -- Marc Glisse