From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113376 invoked by alias); 12 Jan 2017 11:01:23 -0000 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 Received: (qmail 113364 invoked by uid 89); 12 Jan 2017 11:01:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:REGNO_O, sk:regno_o, Sounds X-HELO: mail-wj0-f178.google.com Received: from mail-wj0-f178.google.com (HELO mail-wj0-f178.google.com) (209.85.210.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jan 2017 11:01:16 +0000 Received: by mail-wj0-f178.google.com with SMTP id ew7so9212162wjc.3 for ; Thu, 12 Jan 2017 03:01:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nsII/Iw/jS5DBl3hj/CW9kV8QIMi1tORVwdsQr5HDw4=; b=tGbjHbtTXQKD1WsBpTvtJlLkNnoFzbHqXrE0C5yciIzovqhAsHpYHGNmzTiJV+fmIs QHXpQ36ZW4vLS7My5FHncwG1HCbbqrOJlw/aJs2U31ABh24yuxz2zNjKleDpFNqCkAZ3 QMuSVv/40wwZmc+0ikcSAdjFlQo46EEifUH2Cx9hBNz+MHkXib7PxcJdn9MNwn+cbt1o 1O+j3ytxlxoZxUr4bI4jMeIZjsPSFrhHlWLc+e9rj/hKTc3AUjw75C6Wl3Z0kmz1W7Vj qk8QrxefERW0h10vpZT7WPmhI2v1Ue3ql2FxVTzkP3PF563alCiSI6F2AZQa9K7h17sS ThVQ== X-Gm-Message-State: AIkVDXLIL3mFl6Pc49kxA2Rxb6ABCD0IZ++2d0aMv/7hQ92zMSf+5Sbr1FV+b44iqpp5tg== X-Received: by 10.194.92.204 with SMTP id co12mr7884473wjb.75.1484218873769; Thu, 12 Jan 2017 03:01:13 -0800 (PST) Received: from [10.15.38.164] ([92.103.127.250]) by smtp.gmail.com with ESMTPSA id 135sm2568991wmh.14.2017.01.12.03.01.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 03:01:12 -0800 (PST) Subject: Re: input address reload issue To: Jeff Law , gcc@gcc.gnu.org References: <094e7c3d-fc6c-1b0a-29c3-263cadec25a7@gmail.com> <43773302-1453-5c82-4da0-cf5332aeb8e2@redhat.com> <2382badb-93c4-3799-350f-659e73d25c86@gmail.com> <0a6f7007-2caa-1829-a3df-2b233ac84880@redhat.com> From: Aurelien Buhrig Message-ID: <6e861e1a-421b-02b2-e593-c5bd31432965@gmail.com> Date: Thu, 12 Jan 2017 11:01:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0a6f7007-2caa-1829-a3df-2b233ac84880@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-01/txt/msg00098.txt.bz2 On 09/01/2017 19:35, Jeff Law wrote: > On 01/09/2017 07:02 AM, Aurelien Buhrig wrote: >> On 06/01/2017 17:06, Jeff Law wrote: >>> On 01/06/2017 03:20 AM, Aurelien Buhrig wrote: >>>> >>>>>> So the insn: >>>>>> (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1)) >>>>>> >>>>>> is transformed into: >>>>>> (set (reg:SI 8 a0) (reg:SI 2 r2)) >>>>>> (set (reg:SI 8 a0) (const_int 1)) >>>>>> (set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0))) >>>>>> (set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0)) >>>>>> >>>>>> This "basic" transformation requires two reload regs, but only >>>>>> one is >>>>>> given/used/possible from the rl structure (in emit_reload_insns). >>>>>> >>>>>> So where does the issue comes from? The need for 2 reload regs, the >>>>>> transformation which is too "basic" and could be optimized to use >>>>>> only >>>>>> one reload reg, or any wrong/missing reload target hook? >>>>> Sounds like you need secondary or intermediate reloads. >>>> Do you suggest the secondary reload must implement a scratch reg & md >>>> pattern to implement this reload? >>> Perhaps. I don't know enough about your architecture to be 100% sure >>> about how all the pieces interact with each other -- reload, and >>> secondary reloads in particular are a complex area. I'm largely going >>> on your comment that you need 2 reload registers. >>> >>> Presumably you don't have an instruction for >>> (set (reg) (plus (reg) (const_int))) >>> >>> Thus you need two scratch reload regs IIUC. One to hold r2 another to >>> hold (const_int 1). So you'd want to generate >>> >>> (set (areg1) (reg r2)) >>> (set (areg2) (const_int 1)) >>> (set (areg1) (plus (areg1) (areg2) >>> (set (r0) (mem (areg1)) >>> >>> Or something along those lines. If you're going to stick with reload, >>> you'll likely want to dig into find_reloads_address and its children >>> to see what reloads it generates and why (debug_reload can be helpful >>> here). >> >> Thank you very much Jeff for your help. The best mapping for my target >> would be: >> (set areg1 r2) (set r0 (mem:QI (areg1 + 1)), and only 1 scratch would be >> needed. > So if you've got reg+d addressing modes, then I'd start by looking at > your GO_IF_LEGITIMATE_ADDRESS, REG_OK_FOR_*_P, etc. Reload ought to > be able to reload r2 into an address register without defining > secondary reloads. From what you've described, it's comparable to any > target that has split address/data registers. TARGET_LEGITIMATE_ADDRESS and REGNO_OK_FOR_BASE_P are OK. After trying to debug emit_input_reload, I decided to give LRA a try (and remove cc0). This fixes my reload issue ! Thanks for your help and advice. Aurélien