From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 3243C3858C2C for ; Tue, 9 Nov 2021 00:26:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3243C3858C2C Received: by mail-pl1-x634.google.com with SMTP id o14so17660829plg.5 for ; Mon, 08 Nov 2021 16:26:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=T/t/XtwcnHqXw4WtsNmVebTxSsj91L9qnQFN7SJuDfM=; b=nyohkTdS3rGsveg6CTUuy5SvOc2shDiLOpEKEWAkH9TYEGiQ9Lga7a5ptOubjW1BqD LtqGBF3I03zuoqCvjkSUjLukxrNvZGcfbnXbj57tVfqPtBKJhorVpVstJp99WDbX/DvX 7/Xa0RWEt42jjZvvmM5IQPBLHzekKUV0HoGMzgh0+pf8SqAECpVa9A52nG5W+TIzH6oI xraHmDTnZNTEKgBGK/CUT4hciA2gvSZzPl5XwBwfuNQp+VeW1iA1MdkepL8NI1shyxF4 KTWIv4dV7bVzBMTZlXoG0miYY//nOpIh+NdNRXHCJVoG5N6tQcIBUmXGNI7z152fg3YF F0hw== X-Gm-Message-State: AOAM531d/z9SPacrX51wasTcZPU5L05SgXOKpl7aEv4DbQUd9lE+gstK OxQ/zmKMpLHfbgAwAwMFj6g= X-Google-Smtp-Source: ABdhPJyZsAYnGg9MbArISTASScODMPGK1vtPahYysJ99cw6oBRHerH9T+kwoOCHojVML8fwJ/XOp6g== X-Received: by 2002:a17:90b:2251:: with SMTP id hk17mr2570055pjb.31.1636417583145; Mon, 08 Nov 2021 16:26:23 -0800 (PST) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id d15sm16901191pfj.156.2021.11.08.16.26.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 16:26:22 -0800 (PST) Message-ID: Date: Mon, 8 Nov 2021 17:26:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH] PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing Content-Language: en-US To: "Maciej W. Rozycki" Cc: gcc-patches@gcc.gnu.org, Ulrich Weigand , Richard Sandiford References: <3d74d8f5-2182-abc9-6c06-cf8a9b8f94de@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 09 Nov 2021 00:26:25 -0000 On 11/4/2021 6:18 PM, Maciej W. Rozycki wrote: > On Thu, 4 Nov 2021, Jeff Law wrote: > >> Sometimes the language we're using in email is not as crisp as it should be.  So >> just to be clear, the canonicalization I'm referring to is only in effect within >> a MEM.  It does not apply to address calculations that happen outside a MEM.  I >> think that is consistent with Richard's comments. > Ah, OK then. > >>> and then reload substitutes (reg/v:SI 154 [ n_ctrs ]) with the inner MEM >>> as it fails to reload the pseudo and just uses its memory location. >> OK.  So what I still don't see is why  we would need to re-recognize.   You're >> changing code that I thought was only applicable when we were reloading an >> address inside a MEM and if we're inside a MEM, then we shouldn't be seeing an >> ASHIFT.   We're replacing the argument of the ASHIFT. > Well, the context of this code (around and including hunk #1) is: > > else if (insn_extra_address_constraint > (lookup_constraint (constraints[i]))) > { > address_operand_reloaded[i] > = find_reloads_address (recog_data.operand_mode[i], (rtx*) 0, > recog_data.operand[i], > recog_data.operand_loc[i], > i, operand_type[i], ind_levels, insn); > > /* If we now have a simple operand where we used to have a > PLUS or MULT, re-recognize and try again. */ > if ((OBJECT_P (*recog_data.operand_loc[i]) > || GET_CODE (*recog_data.operand_loc[i]) == SUBREG) > && (GET_CODE (recog_data.operand[i]) == MULT > || GET_CODE (recog_data.operand[i]) == PLUS)) > { > INSN_CODE (insn) = -1; > retval = find_reloads (insn, replace, ind_levels, live_known, > reload_reg_p); > return retval; > } > > so the body of the conditional is specifically executed for an address and > not a MEM; in this particular case matched with the plain "p" constraint. > > MEMs are handled with the next conditional right below. Ah!  Thanks for the clarification.  We're digging deep into history here.  I always thought this code was re-recognizing inside a MEM, but as you note, it's actually handling stuff outside the MEM, such as  a 'p' constraint, which is an address, but being outside a MEMS means its not subject to the mult-by-power-of-2 canonicalization. So I think the first hunk is fine.  There's two others that twiddle find_reloads_address_1, which I think can only be reached from find_reloads_address.  The comment at the front would indicate it's only called where AD is inside a MEM. Are we getting into find_reloads_address_1 in any case where the RTL is not an address inside a MEM? jeff