From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by sourceware.org (Postfix) with ESMTPS id B1C92385DC00; Fri, 3 Apr 2020 23:51:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B1C92385DC00 Received: by mail-pf1-x441.google.com with SMTP id f206so4382218pfa.10; Fri, 03 Apr 2020 16:51:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yg/fjkdVLk/40+KIv0Z+yuUmwbESyjKxKcPx8O+93xM=; b=e+0jImFZxm9l5Db2CsTCm5jr9MROaido2y4/yXGTDnqMerDjkDm1EawNosF7YmPHrx 1N7EwP6qeSX7BSZdBz4pswoVFe3/rtAjcRl2ULl5stLSmST2SK8sf7NiV8qV/D3Psl3h kq71FsDA6TyM5mx0vJawAmaqOY8Xl+xoI/yOM0AV1ciy3Fsghr504ONz171rM9VfbEFl vSjplUF6lbZvuGYv4wZ7CK0mdz/iH2LzqwnGB+RkaDVk+TNlBssUU4HlbDtoVCPdR7SR 3kWfvem/qE1LxtLlRV3mGrKYsAxTb7fv6I/TGT4vGMVS0g1xksdNVLpiGRq+hPRRfY68 VzWw== X-Gm-Message-State: AGi0Pub422IUkxHJcGrGssm9L349qG3WAe84efDtq/9stbvIZcaejQdN H6Jk9wRjVF4jHUzebcES/6sCudkp5cU= X-Google-Smtp-Source: APiQypKtnNbdrp1z0oNuHZe97E6aAcIEN/fqH5YjQYeTVIN+OiTjMgMPmBMtUeA5cEiFG+WYdJkP5g== X-Received: by 2002:a62:520a:: with SMTP id g10mr10765229pfb.271.1585957864537; Fri, 03 Apr 2020 16:51:04 -0700 (PDT) Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:746f:405d:7daa:4a17]) by smtp.gmail.com with ESMTPSA id c15sm5920657pgk.66.2020.04.03.16.51.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2020 16:51:03 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 148A488DB0; Sat, 4 Apr 2020 10:21:00 +1030 (ACDT) Date: Sat, 4 Apr 2020 10:21:00 +1030 From: Alan Modra To: Segher Boessenkool Cc: luoxhu , wschmidt@linux.ibm.com, gcc-patches@gcc.gnu.org, linkw@gcc.gnu.org Subject: Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization Message-ID: <20200403235059.GI4583@bubble.grove.modra.org> References: <20200326100643.32487-1-luoxhu@linux.ibm.com> <20200327143331.GD22482@gate.crashing.org> <388143a3-7889-0476-abd7-d2e9b667e5f4@linux.ibm.com> <20200402221653.GG26902@gate.crashing.org> <596ce54a-996c-3180-dbf1-df5e94ded4cb@linux.ibm.com> <20200403121349.GH4583@bubble.grove.modra.org> <20200403211132.GL26902@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200403211132.GL26902@gate.crashing.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 23:51:08 -0000 On Fri, Apr 03, 2020 at 04:11:32PM -0500, Segher Boessenkool wrote: > On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote: > > Segher probably meant the part I'm working on and haven't posted yet, > > fixing lots of problems with rs6000_rtx_costs. > > I meant PR94393 in fact, but yeah, this is connected *everywhere* :-) > > > One of the improvements > > I'm aiming for is that we should be able to emit code that loads > > constants from memory without following optimisation passes converting > > the loads from memory to those long sequences of dependent instructions. > > Yeah. Looking forward to it :-) I have a series of small patches already, the most significant so far being the one that adds the following comment to rs6000_rtx_costs: "Calls from places like optabs.c:avoid_expensive_constant will come here with OUTER_CODE set to an operation such as AND with X being a CONST_INT or other CONSTANT_P type. This will be compared against set_src_cost, where we'll come here with OUTER_CODE as SET and X the same constant. Calls from places like default_noce_conversion_profitable_p will come here via seq_cost and pass the pattern of a SET insn in X. The SET isn't handled here so *TOTAL will remain as COSTS_N_INSNS(1) multiplied by the number of words being set. Presuming the insn is valid and set_dest a reg, rs6000_rtx_costs will next see the set_src. Continuing the example of an AND, this might be an AND of two other regs. This AND should cost zero here since the insn cost has already been counted. The overall cost value should be comparable to rs6000_insn_cost." It pays to figure out what you need to do before doing anything. :-) Those two paragraphs will result in quite a few changes. The first one means that, for example, the rs6000_is_valid_and_mask test belongs under case CONST_INT as || (outer_code == AND && rs6000_is_valid_and_mask (x, mode)) not under case AND. The second paragraph says we are costing practically all operations too highly. I'm still in analysis mode, worried about whether gcc generates deep rtl expressions to pass to rtx_cost. I have a vague recollection of seeing that years ago, but it looks like most places with anything complex generate a sequence of insns and cost the sequence. If we do have expressions like (set (reg1) (and (plus (reg2) cst1) cst2)) then rs6000_rtx_cost should recognise that AND as costing an extra insn. -- Alan Modra Australia Development Lab, IBM