From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107744 invoked by alias); 22 Feb 2017 23:01:25 -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 107586 invoked by uid 89); 22 Feb 2017 23:01:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=revalidating X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Feb 2017 23:01:19 +0000 Received: by mail-wm0-f68.google.com with SMTP id u63so2943929wmu.2 for ; Wed, 22 Feb 2017 15:01:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=99r8LuY8K1/pUl8NsYPKmjqy9wCKp4ze8AkwJMwrhcA=; b=oFASGF82HY18ODa6O/u7h2h47OFVN/s2EGYA81GBoa0tdKHWKLRKtzs19mbVYe6S1q GR9ZRQlCehjRMkT2RmWxqx3moYL2ow75zLORfCrz34+z+1RYuxFgzhLiZ+vXH4vJZrPw ivaGW8oZ9Nw00xs3PnXd/PATPAFms6KMltG3C/nMZ4x/O8i2PUOCvsws+lGKhIDjow4j 9g2UOmWquLfS66e2RIvAXf2WeGG9gtoiyIXG8fXGHYRQ68wSuBVKOpbMRqyPsKEirEb3 jAtASMvV0W+69lFpbfbbd5TIuk49xKkzZnTyeiNZxREB6heQgJNQijk1XAMiQSr7H2s8 eXLw== X-Gm-Message-State: AMke39mD0qNIelDT3DYp42CljAIEIn6EkRoLpjjMDu/WMWHI5rux242slcSK8DuHT4RAXA== X-Received: by 10.28.148.76 with SMTP id w73mr727482wmd.74.1487804477553; Wed, 22 Feb 2017 15:01:17 -0800 (PST) Received: from localhost ([2.25.234.124]) by smtp.googlemail.com with ESMTPSA id l67sm3809312wmf.1.2017.02.22.15.01.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 Feb 2017 15:01:16 -0800 (PST) From: Richard Sandiford To: Alan Modra Mail-Followup-To: Alan Modra ,gcc-patches@gcc.gnu.org, Vladimir Makarov , rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, Vladimir Makarov Subject: Re: [PATCH] PR79584, lra ICE in base_to_reg References: <20170222202522.GK14945@bubble.grove.modra.org> Date: Wed, 22 Feb 2017 23:14:00 -0000 In-Reply-To: <20170222202522.GK14945@bubble.grove.modra.org> (Alan Modra's message of "Thu, 23 Feb 2017 06:55:22 +1030") Message-ID: <87r32pltj8.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-02/txt/msg01414.txt.bz2 Alan Modra writes: > This patch allows lra to reload a lo_sum address. Given a mem with a > lo_sum address as used by ppc32, decompose_mem_address returns an > address_info with *base the lo_sum and *base_term the reg within the > lo_sum. When a lo_sum address isn't valid, we want to first try > reloading the entire lo_sum to a new reg. I first fixed that, then > hit another ICE, this time in gen_int_mode. gen_int_mode was being > called with the mode of the memory access, not the mode of the > address. It seems odd that we have a lo_sum address for a mode that doesn't accept lo_sums. I don't think that was one of the "three" cases anticapted in: /* There are three cases where the shape of *AD.INNER may now be invalid: 1) the original address was valid, but either elimination or equiv_address_substitution was applied and that made the address invalid. 2) the address is an invalid symbolic address created by force_const_to_mem. 3) the address is a frame address with an invalid offset. 4) the address is a frame address with an invalid base. All these cases involve a non-autoinc address, so there is no point revalidating other types. */ It sounds from the PR comments like a valid lo_sum in a mem:SI somehow becomes an invalid lo_sum in a mem:SD through equivalence, is that right? If so, was there a (subreg:SD (reg:SI ...)) in the pre-RA insn that got "simplifed" to a (mem:SD (lo_sum ...)) during LRA? IMO the bug's in that step if so and if lo_sum isn't valid for mem:SD. The patch instead seems to be moving towards reloading any address we end up with (which presumably fits one of the options above for _some_ mode, just not in this case for the current mode). But then there's no reason why the remaining assert: > @@ -2916,18 +2916,18 @@ base_to_reg (struct address_info *ad) > rtx_insn *insn; > rtx_insn *last_insn = get_last_insn(); > > - lra_assert (ad->base == ad->base_term && ad->disp == ad->disp_term); > + lra_assert (ad->disp == ad->disp_term); would hold either. We'd need to make base_to_reg handle every address recognised by decompose_mem_address, including for instance cases in which an index could be sign-extended for the original mem mode but not for the current one. I don't think the code was ever intended to handle anything that complicated. The address has to be "basically" valid, except in the cases above. Thanks, Richard