From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105720 invoked by alias); 1 Sep 2015 22:13:59 -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 105701 invoked by uid 89); 1 Sep 2015 22:13:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 01 Sep 2015 22:13:58 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id BD52D2EEE; Tue, 1 Sep 2015 22:13:56 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t81MDtUi012677; Tue, 1 Sep 2015 18:13:56 -0400 Subject: Re: [PATCH][optabs][ifcvt][1/3] Define negcc, notcc optabs To: Kyrill Tkachov , GCC Patches References: <55E5BE7F.2040600@arm.com> Cc: Marcus Shawcroft , Richard Earnshaw , Ramana Radhakrishnan , James Greenhalgh From: Jeff Law Message-ID: <55E62323.8030401@redhat.com> Date: Tue, 01 Sep 2015 22:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55E5BE7F.2040600@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00100.txt.bz2 On 09/01/2015 09:04 AM, Kyrill Tkachov wrote: > Hi all, > > This first patch introduces the negcc and notcc optabs that should > expand to a conditional > negate or a conditional bitwise complement operation. > > These are used in ifcvt.c to transform code of the form: > if (test) x = -A; else x = A; > into: > x = A; if (test) x = -x; > where the "if (test) x = -x;" is implemented using the negcc (or notcc > in the ~x case) > if such an optab is available. If such an optab is not implemented then > no transformation > is performed. Thus, without patches 2/3 and 3/3 this patch does not > impact behaviour on any target. > > Bootstrapped and tested as part of the series on arm, aarch64, x86_64. > > Ok for trunk? > > Thanks, > Kyrill > > 2015-09-01 Kyrylo Tkachov > > * ifcvt.c (noce_try_inverse_constants): New function. > (noce_process_if_block): Call it. > * optabs.h (emit_conditional_neg_or_complement): Declare prototype. > * optabs.def (negcc_optab, notcc_optab): Declare. > * optabs.c (emit_conditional_neg_or_complement): New function. > * doc/tm.texi (Standard Names): Document negcc, notcc names. > > negnotcc-optabs.patch > > > commit a2183218070ed5f2dca0a9651fdb08ce134ba8ee > Author: Kyrylo Tkachov > Date: Thu Aug 13 18:14:52 2015 +0100 > > [optabs][ifcvt][1/3] Define negcc, notcc optabs > > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi > index 0bffdc6..5038269 100644 > --- a/gcc/doc/md.texi > +++ b/gcc/doc/md.texi > @@ -5791,6 +5791,21 @@ move operand 2 or (operands 2 + operand 3) into operand 0 according to the > comparison in operand 1. If the comparison is false, operand 2 is moved into > operand 0, otherwise (operand 2 + operand 3) is moved. > > +@cindex @code{neg@var{mode}cc} instruction pattern > +@item @samp{neg@var{mode}cc} > +Similar to @samp{mov@var{mode}cc} but for conditional negation. Conditionally > +move the negation of operand 2 operand 3 into operand 0 according to the > +comparison in operand 1. If the comparison is true, the negation of operand 2 > +is moved into operand 0, otherwise operand 3 is moved. > + > +@cindex @code{not@var{mode}cc} instruction pattern > +@item @samp{not@var{mode}cc} > +Similar to @samp{neg@var{mode}cc} but for conditional complement. > +Conditionally move the bitwise complement of operand 2 operand 3 into operand 0 > +according to the comparison in operand 1. If the comparison is true, > +the complement of operand 2 is moved into operand 0, otherwise operand 3 is > +moved. "operand 2 operand 3" does not parse. I think you mean "operand 2 or operand 3" in both instances above. Even that doesn't parse well as it's not clear if operand3 or the negation/complement of operand 3 is meant. Can you try to improve the ambiguity of the second sentence in each description. And just a note. The canonical way to refer to these patterns should be negcc/notcc. That avoids conflicting with the older negscc patterns with different semantics that are defined by some ports. You're already using that terminology, so there's nothing to change, I just wanted to point it out. + > + rtx_code code; > + if (val_a == -val_b) Do we have to worry about signed overflow here? I'm thinking specifically when val_b is the smallest possible integer representable by a HOST_WIDE_INT. I suspect you may be able to avoid these problems with judicious use of the hwi interfaces. So I think we just need to resolve the doc change and make sure we're not triggering undefined behaviour above and this can go forward. jeff