From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22713 invoked by alias); 24 Oct 2011 09:45:39 -0000 Received: (qmail 22702 invoked by uid 22791); 24 Oct 2011 09:45:37 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BQ,TW_DD,TW_DQ X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Oct 2011 09:45:22 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RIH5r-0002yT-I4 for gcc@gcc.gnu.org; Mon, 24 Oct 2011 11:45:19 +0200 Received: from 193.128.72.68 ([193.128.72.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Oct 2011 11:45:19 +0200 Received: from paulo by 193.128.72.68 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Oct 2011 11:45:19 +0200 To: gcc@gcc.gnu.org From: "Paulo J. Matos" Subject: Re: Expanding instructions with condition codes inter-deps Date: Mon, 24 Oct 2011 12:07:00 -0000 Message-ID: References: <4E9E0775.3020303@redhat.com> <09787EF419216C41A903FD14EE5506DD030CD64EDB@AUSX7MCPC103.AMER.DELL.COM> <4EA1E726.6090204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: <4EA1E726.6090204@redhat.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00418.txt.bz2 On 21/10/11 22:41, Richard Henderson wrote: > On 10/21/2011 10:15 AM, Paulo J. Matos wrote: >> So I have implemented the nadd and addc as: >> >> (define_insn "negqi2" >> [(set (match_operand:QI 0 "register_operand" "=c") >> (neg:QI (match_operand:QI 1 "register_operand" "0"))) >> (set (reg:CC_C RCC) (eq (match_dup 1) (const_int 0))) >> (clobber (reg:CC RCC))] >> "" >> { >> operands[2] = const0_rtx; >> return "nadd\\t%0,%2"; >> }) > > There are lots of parts of the compiler that don't optimize well when an > insn has more than one output. For the normal insn, just clobber the flags; > don't include a second SET. > But this case is not a normal insn per se, I did this to negqi2 because I need GCC to know that this instruction explicitly changes RCC and that the following instruction will use the carry flag (addc). The reason I say it is not a normal insn is because it comes often in a pair negqi2 / addc_internal, like for example addqi3 / addc_internal or subqi3 / subc_internal. >> (define_insn "addc_internal" >> [(set (match_operand:QI 0 "nonimmediate_operand" "=c") >> (plus:QI >> (plus:QI >> (ltu:QI (reg:CC RCC) (const_int 0)) >> (match_operand:QI 1 "nonimmediate_operand" "%0")) >> (match_operand:QI 2 "general_operand" "cwmi"))) >> (use (reg:CC_C RCC)) >> (clobber (reg:CC RCC))] >> "" >> "addc\\t%0,%f2") > > You don't need the USE, because you mention RCC inside the LTU. > >> (define_insn "*addc_internal_flags" > > Likewise. > Got it, thanks. >> A couple of things to note: >> * negqi (which generates the nadd x, y equivalent to -x + y) has a >> set RCC in C mode followed by a clobber. The set in C mode doesn't >> show up in the _flags variant which is used only for the compare-elim >> since it doesn't really matter and it already contains a set RCC >> anyway. > > Surely the NADD insn is simply a normal subtract (with reversed operands). > You shouldn't *need* to implement NEG at all, as the middle-end will let > NEG expand via MINUS. > > Just so you know... > But it is not exactly the same thing in this arch because: subqi3 generates a sub , == = - to represent negqi2 of register R with a nadd I just do: nadd R,#0 to represent it using a sub I require more moves: ld R1, #0 sub R1, @R ; @R is memory mapped R ld R, @R1 >> * is this enough for GCC to understand that anything that clobbers >> RCC or specifically touches the RCC in C mode shouldn't go in between >> these two instructions? > > Yes. > >> Also, do I need to specify in the RCC >> clobber, exactly which flags are clobbered, or should I use a set >> instead? > > No, the compiler will assume the entire register is changed, no matter > what CCmode you place there. > Got it, so the only way to deal with the carry flag by itself would be to represent the Carry flag as a separate flags register. Although that would require more than one flags register and it feels messy. -- PMatos