From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86774 invoked by alias); 20 Mar 2018 16:07:36 -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 86689 invoked by uid 89); 20 Mar 2018 16:07:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_NUMSUBJECT,T_RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=ham version=3.3.2 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Mar 2018 16:07:33 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w2KG7NvU031320; Tue, 20 Mar 2018 11:07:24 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id w2KG7Khm031319; Tue, 20 Mar 2018 11:07:20 -0500 Date: Tue, 20 Mar 2018 16:21:00 -0000 From: Segher Boessenkool To: Michael Meissner , GCC Patches , David Edelsohn , Bill Schmidt Subject: Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #4 Message-ID: <20180320160719.GI21977@gate.crashing.org> References: <20180314225408.GA3365@ibm-tiger.the-meissners.org> <20180316165045.GA14438@ibm-tiger.the-meissners.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180316165045.GA14438@ibm-tiger.the-meissners.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00976.txt.bz2 Hi Mike, On Fri, Mar 16, 2018 at 12:50:45PM -0400, Michael Meissner wrote: > --- gcc/config/rs6000/rs6000-output.c (revision 258576) > +++ gcc/config/rs6000/rs6000-output.c (working copy) > @@ -162,7 +162,13 @@ rs6000_output_move_64bit (rtx operands[] > > /* Moves to SPRs. */ > else if (reg_is_spr_p (dest)) > - return "mt%0 %1"; > + { > + if (src_gpr_p) > + return "mt%0 %1"; > + > + else if (dest_regno == src_regno) > + return "nop"; > + } > } Is this correct? Many SPRs are not simple registers, they do something when you write to them. But I guess this is only for lr,ctr,vrsave (i.e. regclass "h", "SPECIAL_REGS"). So maybe we want a better name? > +;; STD LD MR MT MF G-const > +;; H-const F-const Special > + > (define_insn "*mov_softfloat64" > - [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=Y,r,r,cl,r,r,r,r,*h") > - (match_operand:FMOVE64 1 "input_operand" "r,Y,r,r,h,G,H,F,0"))] > + [(set (match_operand:FMOVE64 0 "nonimmediate_operand" > + "=Y, r, r, cl, r, r, > + r, r, *h") > + > + (match_operand:FMOVE64 1 "input_operand" > + "r, Y, r, r, h, G, > + H, F, 0"))] > + > "TARGET_POWERPC64 && TARGET_SOFT_FLOAT > - && (gpc_reg_operand (operands[0], mode) > - || gpc_reg_operand (operands[1], mode))" > - "@ > - std%U0%X0 %1,%0 > - ld%U1%X1 %0,%1 > - mr %0,%1 > - mt%0 %1 > - mf%1 %0 > - # > - # > - # > - nop" > - [(set_attr "type" "store,load,*,mtjmpr,mfjmpr,*,*,*,*") > - (set_attr "length" "4,4,4,4,4,8,12,16,4")]) > + && rs6000_valid_move_p (operands[0], operands[1])" > + "* return rs6000_output_move_64bit (operands);" > + [(set_attr "type" > + "store, load, *, mtjmpr, mfjmpr, *, > + *, *, *") > + > + (set_attr "length" > + "4, 4, 4, 4, 4, 8, > + 12, 16, 4")]) Let's take this one as example. The attributes depend on which alternative is selected, but with your change the actual output insn does not. That is no good. Maybe you can reduce the number of alternatives? Make it just store, load, and moves for example, and then select the attributes based on what machine insns you actually output? The ones that are split are the problematic ones in that case, the rest is easy to handle. Segher