From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127380 invoked by alias); 20 Apr 2019 08:55: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 127369 invoked by uid 89); 20 Apr 2019 08:55:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Received:Sat, reintroduced, hello!, stumbled X-HELO: mail-it1-f193.google.com Received: from mail-it1-f193.google.com (HELO mail-it1-f193.google.com) (209.85.166.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 20 Apr 2019 08:55:55 +0000 Received: by mail-it1-f193.google.com with SMTP id q14so3987006itk.0 for ; Sat, 20 Apr 2019 01:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WDnEvMsslChhJBpjIkScq0lfpJoHMPZ8uPSE5OC5DCA=; b=tJl+uIBKEuMfCTtNQHpfSKrBy7l6sz/4bGGHMH65SjaTRUB5pXkWEL3eCkADGJtDNk bGb5Lno8J/G7O11yn50cxo+ZxB6QgPEgc/pe4zDriEhNYQbwJGgy4rSiEyz/Sd29X7eo GadD9Uq4E8+h3jPQ+2IHwM2XeeSVR6X7J9Lbm5o2OWbXX3IW8Mzu9xY7GNV+T/MIp0Uf WDX2XwzZv2alCtkrEAyHiYH8QbVwg7gBCUhaBlOWRsJ0RqIAG/lqEbAcG9PSWvgO2HBD soj9t2g9nNQK/un+uUFRCoS3ya/eEgnwE0/shf4PpQi7I1clYdHlnFgNxoOP3nxcafBw s7nA== MIME-Version: 1.0 Received: by 2002:a02:954b:0:0:0:0:0 with HTTP; Sat, 20 Apr 2019 01:55:52 -0700 (PDT) In-Reply-To: <6d8d4025-5564-922e-912c-3ac1f812c132@redhat.com> References: <6d8d4025-5564-922e-912c-3ac1f812c132@redhat.com> From: Uros Bizjak Date: Sat, 20 Apr 2019 15:38:00 -0000 Message-ID: Subject: Re: [PATCH, LRA]: Revert the revert of removal of usless move insns. To: Vladimir Makarov Cc: "gcc-patches@gcc.gnu.org" , Jeff Law , "H.J. Lu" Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-04/txt/msg00825.txt.bz2 On 4/20/19, Vladimir Makarov wrote: > > On 11/21/18 2:33 PM, Uros Bizjak wrote: >> Hello! >> >> Before the recent patch to post-reload mode switching, vzeroupper >> insertion depended on the existence of the return copy instructions >> pair in functions that return a value. The first instruction in the >> pair represents a move to a function return hard register, and the >> second was a USE of the function return hard register. Sometimes a nop >> move was generated (e.g. %eax->%eax) for the first instruction of the >> return copy instructions pair and the patch [1] teached LRA to remove >> these useless instructions on the fly. >> >> The removal caused optimize mode switching to trigger the assert, >> since the first instruction of a return pair was not found. The >> relevant part of the patch was later reverted. With the recent >> optimize mode switching patch, this is no longer necessary for >> vzeroupper insertion pass, so attached patch reverts the revert. >> >> 2018-11-21 Uros Bizjak >> >> Revert the revert: >> 2013-10-26 Vladimir Makarov >> >> Revert: >> 2013-10-25 Vladimir Makarov >> >> * lra-spills.c (lra_final_code_change): Remove useless move insns. >> >> Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. >> >> OK for mainline? > Sure, Uros. I support the patch. But I think it would be wise to > postpone its committing after releasing GCC-9. Simply it is hard to > predict the patch effect to other targets and I would avoid any risk at > this stage. Actually, the "revert of the revert" patch was already committed to mainline some time ago. To clear the possible misunderstanding, let me summarise the issue: - the original patch that remove useless move insn caused a breakage in vzeroupper pass. - the original patch was reverted due to the above breakage - the vzeroupper pass was later adjusted to tolerate removed useless move instructions, and this cleared the way to revert the revert. Now LRA removes useless move insns. An orthogonal issue (PR90178) was discovered, showing that some passes also depend on the presence of useless move insn. The bisection stumbled on the "revert of the revert" patch that (obviously) re-introduced the issue. I'm not in the position to decide if useless move insn can be removed or if these later passes should be fixed, I can only say that the vzeroupper pass is now agnostic to the presence of useless move insns. Uros.