From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2489 invoked by alias); 7 Jan 2019 22:51:22 -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 2479 invoked by uid 89); 7 Jan 2019 22:51:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Jan 2019 22:51:20 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B8F134CEA8; Mon, 7 Jan 2019 22:51:19 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B81D5D9CA; Mon, 7 Jan 2019 22:51:19 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x07MpHXr026939; Mon, 7 Jan 2019 23:51:17 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x07MpGv9026938; Mon, 7 Jan 2019 23:51:16 +0100 Date: Mon, 07 Jan 2019 22:51:00 -0000 From: Jakub Jelinek To: Uros Bizjak , Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Optimize away x86 mem stores of what the mem contains already (PR rtl-optimization/79593) Message-ID: <20190107225116.GU30353@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00355.txt.bz2 Hi! As mentioned in that PR, we have a SI->DImode zero extension and RA happens to choose to zero extend from a SImode memory slot which is the low part of the DImode memory slot into which the zero extension is to be stored. Unfortunately, the RTL DSE part really doesn't have infrastructure to remember and, if needed, invalidate loads, it just remembers stores, so handling this generically is quite unlikely at least for GCC9. This patch just handles that through a peephole2 (other option would be to handle it in the define_split for the zero extension, but the peephole2 is likely to catch more things). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2019-01-07 Jakub Jelinek PR rtl-optimization/79593 * config/i386/i386.md (reg = mem; mem = reg): New define_peephole2. --- gcc/config/i386/i386.md.jj 2019-01-01 12:37:31.564738571 +0100 +++ gcc/config/i386/i386.md 2019-01-07 17:11:21.056392168 +0100 @@ -18740,6 +18740,21 @@ (define_peephole2 const0_rtx); }) +;; Attempt to optimize away memory stores of values the memory already +;; has. See PR79593. +(define_peephole2 + [(set (match_operand 0 "register_operand") + (match_operand 1 "memory_operand")) + (set (match_dup 1) (match_dup 0))] + "REG_P (operands[0]) + && !STACK_REGNO_P (operands[0]) + && !MEM_VOLATILE_P (operands[1])" + [(set (match_dup 0) (match_dup 1))] +{ + if (peep2_reg_dead_p (1, operands[0])) + DONE; +}) + ;; Attempt to always use XOR for zeroing registers (including FP modes). (define_peephole2 [(set (match_operand 0 "general_reg_operand") Jakub