This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING][PATCH 2/3] retire mem_signal_fence pattern
- From: Jeff Law <law at redhat dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 31 Aug 2017 17:13:08 -0600
- Subject: Re: [PING][PATCH 2/3] retire mem_signal_fence pattern
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3F33680099
- References: <20170802174548.12344-1-amonakov@ispras.ru> <20170802174548.12344-2-amonakov@ispras.ru> <alpine.LNX.2.20.13.1708281408400.16251@monopod.intra.ispras.ru>
On 08/28/2017 06:05 AM, Alexander Monakov wrote:
> Ping (for this and patch 3/3 in the thread).
>
> On Wed, 2 Aug 2017, Alexander Monakov wrote:
>
>> Similar to mem_thread_fence issue from the patch 1/3, RTL representation of
>> __atomic_signal_fence must be a compiler barrier. We have just one backend
>> offering this pattern, and it does not place a compiler barrier.
>>
>> It does not appear useful to expand signal_fence to some kind of hardware
>> instruction, its documentation is wrong/outdated, and we are using it
>> incorrectly anyway. So just remove the whole thing and simply emit a compiler
>> memory barrier in the optabs.c handler.
>>
>> * config/s390/s390.md (mem_signal_fence): Remove.
>> * doc/md.texi (mem_signal_fence): Remove.
>> * optabs.c (expand_mem_signal_fence): Remove uses of mem_signal_fence.
>> Update comments.
>> * target-insns.def (mem_signal_fence): Remove.
This is OK.
What's the point of the delete_insns_since calls in patch #3?
jeff