Message ID | 22dddcdd-d739-4c6d-8da7-d59be94c435f@linux.ibm.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp1848453dyb; Sun, 25 Feb 2024 19:31:05 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVywhMY4nXOcxj92Q4c/rCRGO5gpkRfPCA2k86RuNd7+fpb+XZOQfPxncCMVA6FzzvB8AKEx+DRVzg2EeIKmq3MqF00TQ== X-Google-Smtp-Source: AGHT+IFa/o2GYcHJgRH5kX16BULGtAFAmInpxQPKtU5aaQgVE5ZrwXnyuYyZviX5ivNj/EMNgeGM X-Received: by 2002:a05:622a:510:b0:42e:8c25:8fbd with SMTP id l16-20020a05622a051000b0042e8c258fbdmr131397qtx.12.1708918265166; Sun, 25 Feb 2024 19:31:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708918265; cv=pass; d=google.com; s=arc-20160816; b=QpGKQfD0Zf8ga1sErp5OWaxg1BUKI7V8mrfFfuEP9NUtnAfNlnROn99fwBzkS+8IAm 3H8YGyzBg0rybEbmK+6lZSrS+pEgWjggXATAXdT6KPQKXrnPIe4HrWHT9+twQiDnqp6m UwDMh5VdMEIrcusdNN1cLFi2uZrxy8g6zBlM38Lsqa7dyzZBqNtvQHTER83ue71kyQC3 T8lUlTw1724Kbfk3Bj3SCxkKh6mUeiTF1XiUPQjcuIYtOIbGPqQ5+elC59DHqNmsZyML Ta7KcW/p3PdjNhINTdVpxS898VMjnk/vmlyOc0KoE2pTdFZs08+clVgmg1ySrMV2TRmf Vaiw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :subject:from:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=nKK/zT0SkF7tOh/jVEGSSwMu08IAtNQkfqdgCgEknSU=; fh=lLZP3uHhXiSbgwP2B1KoLJRAVcgP5GU+moaWEakPPkg=; b=pyult3TuQMZF0aC0xf6VkLItTiSqciS/DCgnWsPhdM7iLyXYtyBENfJjq+lt/qfF+K GDfEbL7Louj3+IEJtyldEl4y6K/q0yZUSVbTDfZ1kndmM3KoBSPQ6KUWjtkk5EJerx86 L5i5rvgPq4N+JYvuzgN8Yw4YdicrEkNn8vEjY/5tmmOyHHCdoGbO5dOBXqjXDztSIAQW jmUGKki3VgqaBYVKSaDQmPaHvAaHXPyryY0CCicgVTPqSWB7RodSPRBTZcwlDzS98cav llR4FESPKnlqXq/l0x+90q8UkjGA1aE9bJ11bjoEUsH0hjsHPQpFWwylF/quYzIzoKq/ RwEA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=OJmJVOZr; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id c20-20020a05622a025400b0042e7aae5b87si3440219qtx.675.2024.02.25.19.31.05 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Feb 2024 19:31:05 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=OJmJVOZr; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DC7BA3858C98 for <ouuuleilei@gmail.com>; Mon, 26 Feb 2024 03:31:04 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 2688A3858D1E for <gcc-patches@gcc.gnu.org>; Mon, 26 Feb 2024 03:30:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2688A3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2688A3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708918230; cv=none; b=vKPEkHXnIR1KliM6MRX4Nd9ECw6HCajmNpeTGNWxG1N4fySbTJDQLmp3ZXUsJxFujCPEXj+CxJhRO8L49D78NqnDg37NHKMdCwg4XeNwCeSNzuKBQWnmr0sbqSM9uLamczLzMl2/eBUdzvd/xiBva+buoncgAiFAAsd1dfCjw6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708918230; c=relaxed/simple; bh=ZqazHKYbUvSofswJduHaiq/WIDr8LDbCf+4dWtOq9cY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=Kgx3lgomnZ2gnOJ7l0bKtQflJztedbBp+xmvHsWaPUI/O9IsPeJHGUdYaq+WqQfnDkCR9jmpZirXJ5gfrYdeKAxznk1KZ/rO42xMx+BKth6T+kqmq0mjJCrkyxWlpeLZf93OEYmMMVtok4TmAnwsn19INe7RG1Fdls7bfvJe9ug= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 41Q0Vqwf019827; Mon, 26 Feb 2024 03:30:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : to : cc : from : subject : content-type : content-transfer-encoding; s=pp1; bh=nKK/zT0SkF7tOh/jVEGSSwMu08IAtNQkfqdgCgEknSU=; b=OJmJVOZrOHQE7eb53O6geZK/qvY4hog7686jkYARD1XPnvjlifMfEl3G3YowegSQwSpt 8mDAUvBJ0l6SLsDquoOHuY5Cv3BMgVZJAvZQN8YBQrZQGqsSr4Z9vGT1KHClkp5UgnKC I702Ef/Y5Qku/yx4YMlQYeAzt1D4y/fpYQzU0fQnpGIR7GHNnTFyGa/TOAD+yKJcPvyR JN0zrpUWSIqxxhVliGF1AtVdb4GjOmXtRloT2IYdMJj+MysbY9hqTD8jQwf7FhZAAhbQ wc4Y4gYXz6Mt+XEOY7x2C0u0oXdAmHWp/1MlotTAhPLvo7DlVcDHG5/sHWNktTzkF+sq Cg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3wff352ghh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Feb 2024 03:30:23 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 41Q3GxWP012985; Mon, 26 Feb 2024 03:30:22 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3wff352ggv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Feb 2024 03:30:22 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 41Q35rQV024154; Mon, 26 Feb 2024 03:30:21 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3wfw0jx38n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Feb 2024 03:30:21 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 41Q3UGL22359930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Feb 2024 03:30:18 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2383D2007C; Mon, 26 Feb 2024 03:30:16 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 051572004E; Mon, 26 Feb 2024 03:30:14 +0000 (GMT) Received: from [9.197.226.11] (unknown [9.197.226.11]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 26 Feb 2024 03:30:13 +0000 (GMT) Message-ID: <22dddcdd-d739-4c6d-8da7-d59be94c435f@linux.ibm.com> Date: Mon, 26 Feb 2024 11:30:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: gcc-patches <gcc-patches@gcc.gnu.org> Cc: Segher Boessenkool <segher@kernel.crashing.org>, David <dje.gcc@gmail.com>, "Kewen.Lin" <linkw@linux.ibm.com>, Peter Bergner <bergner@linux.ibm.com>, Richard Sandiford <richard.sandiford@arm.com> From: HAO CHEN GUI <guihaoc@linux.ibm.com> Subject: [PATCH] fwprop: Avoid volatile defines to be propagated Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: vFgiAg1AL7pYMZ-zUlbDuo9M3CdFI--n X-Proofpoint-ORIG-GUID: jqce1Ae51ufSEteZRtHNT8rfNwyAioji X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-26_01,2024-02-23_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 clxscore=1015 mlxscore=0 spamscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 mlxlogscore=737 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402260025 X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791930678984686422 X-GMAIL-MSGID: 1791930678984686422 |
Series |
fwprop: Avoid volatile defines to be propagated
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
HAO CHEN GUI
Feb. 26, 2024, 3:30 a.m. UTC
Hi, This patch tries to fix a potential problem which is raised by the patch for PR111267. The volatile asm operand tries to be propagated to a single set insn with the patch for PR111267. It has potential risk as the behavior is wrong. Currently set_src_cost comparison can reject such propagation. But the propagation might be taken after replacing set_src_cost with insn cost. Actually I found the problem in testing my patch which replacing et_src_cost with insn cost for fwprop. Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no regressions. Is it OK for the trunk? Thanks Gui Haochen ChangeLog fwprop: Avoid volatile defines to be propagated The patch for PR111267 (commit id 86de9b66480b710202a2898cf513db105d8c432f) which introduces an exception for propagation on single set insn. The propagation which might not be profitable (checked by profitable_p) is still allowed to be propagated to single set insn. It has a potential problem that a volatile asm operand will try to be propagated to a single set insn. The volatile asm operand is originally banned in profitable_p. This patch fixes the problem by skipping volatile set source in define set finding. gcc/ * fwprop.cc (forward_propagate_into): Return false for volatile set source. gcc/testsuite/ * gcc.target/powerpc/fwprop-1.c: New. patch.diff
Comments
On 2/25/24 20:30, HAO CHEN GUI wrote: > Hi, > This patch tries to fix a potential problem which is raised by the patch > for PR111267. The volatile asm operand tries to be propagated to a single > set insn with the patch for PR111267. It has potential risk as the behavior > is wrong. Currently set_src_cost comparison can reject such propagation. > But the propagation might be taken after replacing set_src_cost with insn > cost. Actually I found the problem in testing my patch which replacing > et_src_cost with insn cost for fwprop. > > Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no > regressions. Is it OK for the trunk? > > Thanks > Gui Haochen > > ChangeLog > fwprop: Avoid volatile defines to be propagated > > The patch for PR111267 (commit id 86de9b66480b710202a2898cf513db105d8c432f) > which introduces an exception for propagation on single set insn. The > propagation which might not be profitable (checked by profitable_p) is still > allowed to be propagated to single set insn. It has a potential problem > that a volatile asm operand will try to be propagated to a single set insn. > The volatile asm operand is originally banned in profitable_p. This patch > fixes the problem by skipping volatile set source in define set finding. > > gcc/ > * fwprop.cc (forward_propagate_into): Return false for volatile set > source. > > gcc/testsuite/ > * gcc.target/powerpc/fwprop-1.c: New. Why specifically are you worried here? Propagation of a volatile shouldn't in and of itself cause a problem. We're not changing the number of volatile accesses or anything like that -- we're just moving them around a bit. Jeff
Hi Jeff,
Thanks for your comments.
在 2024/3/4 6:02, Jeff Law 写道:
> Why specifically are you worried here? Propagation of a volatile shouldn't in and of itself cause a problem. We're not changing the number of volatile accesses or anything like that -- we're just moving them around a bit.
If the volatile asm operand is in a parallel set, it can't be eliminated
after the propagation. So the define insn and use insn will execute the
volatile asm block twice. That's the problem.
Here is a real case from sanitizer_linux.cpp. The insn 62 has a volatile
asm operands and it is propagated into insn 60. After propagation both
insn 60 and 62 has the volatile asm operand. Thus asm block will be
executed for twice. It causes sanitizer behaves abnormally in my test.
propagating insn 62 into insn 60, replacing:
(set (reg/v:DI 119 [ res ])
(reg:DI 133 [ res ]))
successfully matched this instruction:
(set (reg/v:DI 119 [ res ])
(asm_operands/v:DI ("mr 28, %5
mr 27, %8
mr 3, %7
mr 5, %9
mr 6, %10
mr 7, %11
li 0, %3
sc
cmpdi cr1, 3, 0
crandc cr1*4+eq, cr1*4+eq, cr0*4+so
bne- cr1, 1f
li 29, 0
stdu 29, -8(1)
stdu 1, -%12(1)
std 2, %13(1)
mr 12, 28
mtctr 12
mr 3, 27
bctrl
ld 2, %13(1)
li 0, %4
sc
1:
mr %0, 3
") ("=r") 0 [
(reg:SI 134)
(const_int 22 [0x16])
(const_int 120 [0x78])
(const_int 1 [0x1])
(reg/v:DI 3 3 [ __fn ])
(reg/v:DI 4 4 [ __cstack ])
(reg/v:SI 5 5 [ __flags ])
(reg/v:DI 6 6 [ __arg ])
(reg/v:DI 7 7 [ __ptidptr ])
(reg/v:DI 8 8 [ __newtls ])
(reg/v:DI 9 9 [ __ctidptr ])
(const_int 32 [0x20])
(const_int 24 [0x18])
[
(asm_input:SI ("0") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
]
[] /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591))
rescanning insn with uid = 60.
updating insn 60 in-place
(insn 62 61 60 6 (parallel [
(set (reg:DI 133 [ res ])
(asm_operands/v:DI ("mr 28, %5
mr 27, %8
mr 3, %7
mr 5, %9
mr 6, %10
mr 7, %11
li 0, %3
sc
cmpdi cr1, 3, 0
crandc cr1*4+eq, cr1*4+eq, cr0*4+so
bne- cr1, 1f
li 29, 0
stdu 29, -8(1)
stdu 1, -%12(1)
std 2, %13(1)
mr 12, 28
mtctr 12
mr 3, 27
bctrl
ld 2, %13(1)
li 0, %4
sc
1:
mr %0, 3
") ("=r") 0 [
(reg:SI 134)
(const_int 22 [0x16])
(const_int 120 [0x78])
(const_int 1 [0x1])
(reg/v:DI 3 3 [ __fn ])
(reg/v:DI 4 4 [ __cstack ])
(reg/v:SI 5 5 [ __flags ])
(reg/v:DI 6 6 [ __arg ])
(reg/v:DI 7 7 [ __ptidptr ])
(reg/v:DI 8 8 [ __newtls ])
(reg/v:DI 9 9 [ __ctidptr ])
(const_int 32 [0x20])
(const_int 24 [0x18])
]
[
(asm_input:SI ("0") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
]
[] /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591))
(clobber (reg:DI 29 29))
(clobber (reg:DI 28 28))
(clobber (reg:DI 27 27))
(clobber (reg:DI 0 0))
(clobber (reg:DI 97 ctr))
(clobber (mem:BLK (scratch) [0 A8]))
(clobber (reg:CC 101 1))
(clobber (reg:CC 100 0))
(clobber (reg:SI 98 ca))
]) "/home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp":1591:2 -1
(expr_list:REG_DEAD (reg:SI 134)
(expr_list:REG_DEAD (reg/v:DI 9 9 [ __ctidptr ])
(expr_list:REG_DEAD (reg/v:DI 8 8 [ __newtls ])
(expr_list:REG_DEAD (reg/v:DI 7 7 [ __ptidptr ])
(expr_list:REG_DEAD (reg/v:DI 6 6 [ __arg ])
(expr_list:REG_DEAD (reg/v:SI 5 5 [ __flags ])
(expr_list:REG_DEAD (reg/v:DI 4 4 [ __cstack ])
(expr_list:REG_DEAD (reg/v:DI 3 3 [ __fn ])
(expr_list:REG_UNUSED (reg:CC 101 1)
(expr_list:REG_UNUSED (reg:CC 100 0)
(expr_list:REG_UNUSED (reg:SI 98 ca)
(expr_list:REG_UNUSED (reg:DI 97 ctr)
(expr_list:REG_UNUSED (reg:DI 29 29)
(expr_list:REG_UNUSED (reg:DI 28 28)
(expr_list:REG_UNUSED (reg:DI 27 27)
(expr_list:REG_UNUSED (reg:DI 0 0)
(nil))))))))))))))))))
Thanks
Gui Haochen
On 3/3/24 19:56, HAO CHEN GUI wrote: > Hi Jeff, > Thanks for your comments. > > 在 2024/3/4 6:02, Jeff Law 写道: >> Why specifically are you worried here? Propagation of a volatile shouldn't in and of itself cause a problem. We're not changing the number of volatile accesses or anything like that -- we're just moving them around a bit. > > If the volatile asm operand is in a parallel set, it can't be eliminated > after the propagation. So the define insn and use insn will execute the > volatile asm block twice. That's the problem. Thanks. That's a key piece of information. > > Here is a real case from sanitizer_linux.cpp. The insn 62 has a volatile > asm operands and it is propagated into insn 60. After propagation both > insn 60 and 62 has the volatile asm operand. Thus asm block will be > executed for twice. It causes sanitizer behaves abnormally in my test. Understood. So the key is that if we propagate an operand, but are unable to eliminate the original insn, then we can evaluate the operand (in this case an ASM) more than once? Can the same thing happen with a volatile memory load? I don't think that will be caught by the volatile_insn_p check. Jeff
Hi Jeff,
在 2024/3/4 11:37, Jeff Law 写道:
> Can the same thing happen with a volatile memory load? I don't think that will be caught by the volatile_insn_p check.
Yes, I think so. If the define rtx contains volatile memory references, it
may hit the same problem. We may use volatile_refs_p instead of
volatile_insn_p?
Thanks
Gui Haochen
On 3/4/24 02:12, HAO CHEN GUI wrote: > Hi Jeff, > > 在 2024/3/4 11:37, Jeff Law 写道: >> Can the same thing happen with a volatile memory load? I don't think that will be caught by the volatile_insn_p check. > > Yes, I think so. If the define rtx contains volatile memory references, it > may hit the same problem. We may use volatile_refs_p instead of > volatile_insn_p? Yea. OK with that change. Thanks, jeff
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc index 7872609b336..89dce88b43d 100644 --- a/gcc/fwprop.cc +++ b/gcc/fwprop.cc @@ -854,6 +854,8 @@ forward_propagate_into (use_info *use, bool reg_prop_only = false) rtx dest = SET_DEST (def_set); rtx src = SET_SRC (def_set); + if (volatile_insn_p (src)) + return false; /* Allow propagations into a loop only for reg-to-reg copies, since replacing one register by another shouldn't increase the cost. diff --git a/gcc/testsuite/gcc.target/powerpc/fwprop-1.c b/gcc/testsuite/gcc.target/powerpc/fwprop-1.c new file mode 100644 index 00000000000..07b207f980c --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/fwprop-1.c @@ -0,0 +1,15 @@ +/* { dg-do compile } */ +/* { dg-options "-O1 -fdump-rtl-fwprop1-details" } */ +/* { dg-final { scan-rtl-dump-not "propagating insn" "fwprop1" } } */ + +/* Verify that volatile asm operands doesn't try to be propagated. */ +long long foo () +{ + long long res; + __asm__ __volatile__( + "" + : "=r" (res) + : + : "memory"); + return res; +}