From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19959 invoked by alias); 13 Oct 2012 07:42:21 -0000 Received: (qmail 19949 invoked by uid 22791); 13 Oct 2012 07:42:20 -0000 X-SWARE-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Oct 2012 07:42:14 +0000 Received: by mail-we0-f175.google.com with SMTP id t44so2283131wey.20 for ; Sat, 13 Oct 2012 00:42:13 -0700 (PDT) Received: by 10.180.100.35 with SMTP id ev3mr11027075wib.7.1350114133399; Sat, 13 Oct 2012 00:42:13 -0700 (PDT) Received: from localhost ([2.26.188.227]) by mx.google.com with ESMTPS id j8sm1592376wiy.9.2012.10.13.00.42.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 00:42:12 -0700 (PDT) From: Richard Sandiford To: Vladimir Makarov Mail-Followup-To: Vladimir Makarov ,GCC Patches , rdsandiford@googlemail.com Cc: GCC Patches Subject: Re: RFC: LRA for x86/x86-64 [7/9] -- continuation References: <5064DA43.90803@redhat.com> <87k3uvpxuj.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> Date: Sat, 13 Oct 2012 08:52:00 -0000 In-Reply-To: <87k3uvpxuj.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> (Richard Sandiford's message of "Fri, 12 Oct 2012 15:29:56 +0100") Message-ID: <87vceelsx6.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2012-10/txt/msg01279.txt.bz2 I'm having to correct my own comments again, sorry. Richard Sandiford writes: >> + /* If this is post-increment, first copy the location to the reload reg. */ >> + if (post && real_in != result) >> + emit_insn (gen_move_insn (result, real_in)); > > Nit, but real_in != result can never be true AIUI, and I was confused how > the code could be correct in that case. Maybe just remove it, or make > it an assert? Probably obvious, but I meant "real_in == result" can never be true. "real_in != result" could be removed or turned into an assert. >> + if (GET_CODE (op) == PLUS) >> + { >> + plus = op; >> + op = XEXP (op, 1); >> + } > > Sorry, I'm complaining about old reload code again, but: does this > actually happen in LRA? In reload, a register operand could become a > PLUS because of elimination, but I thought LRA did things differently. > Besides, this is only needed for: > >> + if (CONST_POOL_OK_P (mode, op) >> + && ((targetm.preferred_reload_class >> + (op, (enum reg_class) goal_alt[i]) == NO_REGS) >> + || no_input_reloads_p) >> + && mode != VOIDmode) >> + { >> + rtx tem = force_const_mem (mode, op); >> + >> + change_p = true; >> + /* If we stripped a SUBREG or a PLUS above add it back. */ >> + if (plus != NULL_RTX) >> + tem = gen_rtx_PLUS (mode, XEXP (plus, 0), tem); > > and we shouldn't have (plus (constant ...) ...) after elimination > (or at all outside of a CONST). I don't understand why the code is > needed even in reload. Scratch the thing about needing it for reload. It's obviously the second second operand we're reloading, not the first, and it could well be that an elimination displacement needs to be reloaded via the constant pool. The question for LRA still stands though. Richard