From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 69BAF3849AC6 for ; Fri, 19 Apr 2024 06:24:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 69BAF3849AC6 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 69BAF3849AC6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713507852; cv=none; b=jZZn3PDIoDSevRHQbFbuBF3zXzDKv6Mtm1KS6wfT5ApMeEe1yOVVbz9UlbqcNaIBGgOGpTT+xnHWKN3MZjpBwt9zqGcjbp6G6qTotWzCTcbNAIiVEd1c1g9AcUXhEKi3ydE/QcAvQ8ZZJ9FuN5LYpPUG7PAjamrIZSnqS7B5ckg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713507852; c=relaxed/simple; bh=kcWrklrsFkArfkdOtWn9SJQBe4NrCjHIxIZrGIqXDkE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=bt1yQevtbgz3HeDbq+LBE1kCg30TnQwYudP4Tfk44yYnhM6oSY++BoKywLunRWgAse6SbBz24NK0a+oWLIsBUg4Wx4fxIwQBHKAewr9zcL+UVXmVwcROmpx8Xr0ExkqUNK9JUp4ikTIf4ItjejjLaxwQEDVhd3eZNnzWwIJzMR8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713507850; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=tOGsQTEKHtBCmakvlpquDWjuh7XhpdFu69+kb4r5XfE=; b=J1cQN+i1fdhZVSHhBasoUaRhGsCSfx0AqVYZdQ8nPYTlVpVLs6TxO2yw8WToK8gZ8NTXV9 wv+aZ5wocwaTE/4osJ9H80wbgoB1y1zSqt1/63IrL0ayzudLNhFpX0qXUkED0r8LZLdqE0 H9kwHut0OD814H6sWBBmRvqd8kfc79k= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-182-QUl7vDQePXiWFBSxv5YULA-1; Fri, 19 Apr 2024 02:24:06 -0400 X-MC-Unique: QUl7vDQePXiWFBSxv5YULA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 28C3D385A18A; Fri, 19 Apr 2024 06:24:06 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D8D1E2166B32; Fri, 19 Apr 2024 06:24:05 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 43J6O31Y4097078 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 19 Apr 2024 08:24:04 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 43J6O3B54097077; Fri, 19 Apr 2024 08:24:03 +0200 Date: Fri, 19 Apr 2024 08:24:03 +0200 From: Jakub Jelinek To: Richard Biener , Jeff Law , Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] rtlanal: Fix set_noop_p for volatile loads or stores [PR114768] Message-ID: Reply-To: Jakub Jelinek MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On the following testcase, combine propagates the mem/v load into mem store with the same address and then removes it, because noop_move_p says it is a no-op move. If it was the other way around, i.e. mem/v store and mem load, or both would be mem/v, it would be kept. The problem is that rtx_equal_p never checks any kind of flags on the rtxes (and I think it would be quite dangerous to change it at this point), and set_noop_p checks side_effects_p on just one of the operands, not both. In the MEM <- MEM set, it only checks it on the destination, in store to ZERO_EXTRACT only checks it on the source. The following patch adds the missing side_effects_p checks. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-04-19 Jakub Jelinek PR rtl-optimization/114768 * rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM sets if src has side-effects or for stores into ZERO_EXTRACT if ZERO_EXTRACT operand has side-effects. * gcc.dg/pr114768.c: New test. --- gcc/rtlanal.cc.jj 2024-02-24 12:45:28.674249100 +0100 +++ gcc/rtlanal.cc 2024-04-18 15:09:55.199499083 +0200 @@ -1637,12 +1637,15 @@ set_noop_p (const_rtx set) return true; if (MEM_P (dst) && MEM_P (src)) - return rtx_equal_p (dst, src) && !side_effects_p (dst); + return (rtx_equal_p (dst, src) + && !side_effects_p (dst) + && !side_effects_p (src)); if (GET_CODE (dst) == ZERO_EXTRACT) - return rtx_equal_p (XEXP (dst, 0), src) - && !BITS_BIG_ENDIAN && XEXP (dst, 2) == const0_rtx - && !side_effects_p (src); + return (rtx_equal_p (XEXP (dst, 0), src) + && !BITS_BIG_ENDIAN && XEXP (dst, 2) == const0_rtx + && !side_effects_p (src) + && !side_effects_p (XEXP (dst, 0))); if (GET_CODE (dst) == STRICT_LOW_PART) dst = XEXP (dst, 0); --- gcc/testsuite/gcc.dg/pr114768.c.jj 2024-04-18 15:37:49.139433678 +0200 +++ gcc/testsuite/gcc.dg/pr114768.c 2024-04-18 15:43:30.389730365 +0200 @@ -0,0 +1,10 @@ +/* PR rtl-optimization/114768 */ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-rtl-final" } */ +/* { dg-final { scan-rtl-dump "\\\(mem/v:" "final" { target { ! { nvptx*-*-* } } } } } */ + +void +foo (int *p) +{ + *p = *(volatile int *) p; +} Jakub