From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114583 invoked by alias); 1 Oct 2018 00:57:56 -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 114572 invoked by uid 89); 1 Oct 2018 00:57:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:o66-v6m, sk:bergner X-HELO: mail-oi1-f195.google.com Received: from mail-oi1-f195.google.com (HELO mail-oi1-f195.google.com) (209.85.167.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Oct 2018 00:57:54 +0000 Received: by mail-oi1-f195.google.com with SMTP id l197-v6so9806506oib.8 for ; Sun, 30 Sep 2018 17:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pGRkubMTlOP8TGnnxEWMZBYbb5ie/b1W8XWTPRcXTxQ=; b=aoFbMLDJYN0mGT9fnutpu+LkZYd+JKbdr+8G5lXKOOvdScm9sq4tznyPPwS5SXWFBd YMxP5iee6ncUdRFHRfn9jb57TVQ8KW4bTXyvHdVw4IZdcu05xuKo5vC/E8+tCOaFPAIz 5yHMayXAw9R+yWHuaqYzJbl8b1iXnnb5xK3d3CEV9iyHq0iVwrC5qQmMbdy5TJ4CUOKc gp6QNTcuRO9wa0EZtN8sb96ybtNsbzQr4RZgb2+9Dm4AvH8fjSVSFULyWdHydbjH0Z+/ Ze0MaRbkdgLT+2ZRZ5LFjGoDN30ra8JwjvQjdcm+QW92VKGvHoXm3rkPfoytSO1RMiKS zg0Q== MIME-Version: 1.0 References: <616affd5-5140-8e15-9081-1635f7d4e700@redhat.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 01 Oct 2018 00:57:00 -0000 Message-ID: Subject: Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register To: bergner@linux.ibm.com Cc: Vladimir Makarov , GCC Patches , Jeffrey Law Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00000.txt.bz2 On Sun, Sep 30, 2018 at 1:21 PM Peter Bergner wrote: > > On 9/28/18 4:34 PM, Vladimir Makarov wrote: > > I remember I experimented with value numbering and using it in building > > conflicts (that time it was global.c) but it did not improve the code as > > I expected and made RA much slower. > > Yes, value numbering is not cheap to compute for catching special cases > like this that probably don't happen too often. Handling copies is fairly > cheap and easy though. > > > > We had some PRs with old RA code generation in case of using undefined values. > > I don't remember what problems were exactly but I remember Ken Zadeck worked > > on this too. That is why I probably chose the current scheme of conflict > > building. > > > > May be I was wrong because you testing shows that it is not a problem anymore. > > Maybe it was due to code relying on undefined behavior? Anyway, it'll be good > to let PATCH 1 bake on trunk for a little while before we commit PATCH 2 to > catch any (if they exist) problems related to that change. > > > > The 1st patch is ok for me. You can commit it to the trunk. > > Ok, PATCH 1 is now committed, thanks! > > > > I'll review the second patch on the next week. > > Sounds great as it gives any problems caused or exposed by PATCH 1 time to > be reported. Thanks again! This caused: FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx FAIL: gcc.target/i386/pr63534.c scan-assembler-not movl[ \t]%[^,]+, %ebx FAIL: gcc.target/i386/pr64317.c scan-assembler addl[ \\t]+[$]_GLOBAL_OFFSET_TABLE_, %ebx FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)] for Linux/i686. -- H.J.