From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33753 invoked by alias); 27 Oct 2019 05:58:42 -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 33741 invoked by uid 89); 27 Oct 2019 05:58:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*M:online, H*MI:sk:aecb2ae, H*f:sk:66f754f, H*i:sk:66f754f X-HELO: mailout12.t-online.de Received: from mailout12.t-online.de (HELO mailout12.t-online.de) (194.25.134.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Oct 2019 05:58:39 +0000 Received: from fwd39.aul.t-online.de (fwd39.aul.t-online.de [172.20.27.138]) by mailout12.t-online.de (Postfix) with SMTP id 0702041BAA59; Sun, 27 Oct 2019 06:58:37 +0100 (CET) Received: from yam-desktop (bNSGj4ZXYhHX7mvO46XYr+OPh6LblOm+FkcOZMtLHgxAkaUcAT9V-w8gnrwaHqBgbV@[163.58.16.102]) by fwd39.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1iObZU-2F5Aga0; Sun, 27 Oct 2019 06:58:36 +0100 Message-ID: <0589dfbc04514b24bfe7b7e90047197586a4d5e2.camel@t-online.de> Subject: Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass From: Oleg Endo To: Jeff Law , Andrew Waterman Cc: Craig Blackmore , GCC Patches , Jim Wilson , Ofer Shinaar , Nidal.Faour@wdc.com, Kito Cheng Date: Sun, 27 Oct 2019 07:13:00 -0000 In-Reply-To: <66f754f0-66cb-320e-a256-9750b241e6cd@redhat.com> References: <1572025151-22783-1-git-send-email-craig.blackmore@embecosm.com> <1572025151-22783-2-git-send-email-craig.blackmore@embecosm.com> <66f754f0-66cb-320e-a256-9750b241e6cd@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg01912.txt.bz2 On Sat, 2019-10-26 at 14:04 -0600, Jeff Law wrote: > On 10/26/19 1:33 PM, Andrew Waterman wrote: > > I don't know enough to say whether the legitimize_address hook is > > sufficient for the intended purpose, but I am sure that RISC-V's > > concerns are not unique: other GCC targets have to cope with > > offset-size constraints that are coupled to register-allocation > > constraints. > > Yup. I think every risc port in the 90s faces this problem. I > always > wished for a generic mechanism for ports to handle this problem. > > Regardless, it's probably worth investigating. > What we tried to do with the address mode selection (AMS) optimization some time ago was the following: - Extract memory accesses from the insns stream and put them in "access sequences". Also analyze the address expression and try to find effective base addresses by tracing back address calculations. - For each memory access, get a set of address mode alternatives and the corresponding costs from the backend. The full context of each access is provided, so the backend can detect things like "in this access sequence, FP loads dominate" and use this information to tune the alternative costs. - Given the alternatives and costs for each memory access, the pass would then try to minimize the costs of the whole memory access sequence, taking costs of address modification isnns into account. I think this is quite generic, but of course also complex. The optimization problem itself is hard. There was some research done by others using CPLEX or PBQP solvers. To keep things simple we used a backtracking algorithm and handled only a limited set of scenarios. For example, I think we could not get loop constructs work nicely to improve post-inc address mode utilization. The SH ISA has very similar properties to ARM thumb and RVC, and perhaps others. Advantages would not be limited to RISC only, even CISC ISAs like M68K, RX, ... can benefit from it, as the "proper optimization" can reduce the instruction sizes by shortening the addresses in the instruction stream. If anyone is interested, here is the AMS optimization pass class: https://github.com/erikvarga/gcc/blob/master/gcc/ams.h https://github.com/erikvarga/gcc/blob/master/gcc/ams.cc It's using a different style to callback into the backend code. Not GCC's "hooks" but a delegate pattern. SH backend's delegate implementation is here https://github.com/erikvarga/gcc/blob/master/gcc/config/sh/sh.c#L11897 We were getting some improvements in the generated code, but it started putting pressure on register allocation related issues in the SH backend (the R0 problem), so we could not do more proper testing. Maybe somebody can get some ideas out of it. Cheers, Oleg