This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/3] optabs: ensure mem_thread_fence is a compiler barrier
- From: Jeff Law <law at redhat dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>, Richard Sandiford <richard dot sandiford at linaro dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 14 Aug 2017 14:41:01 -0600
- Subject: Re: [PATCH 1/3] optabs: ensure mem_thread_fence is a compiler barrier
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.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 A126B432C1
- References: <20170802174548.12344-1-amonakov@ispras.ru> <877eyiidxr.fsf@linaro.org> <alpine.LNX.2.20.13.1708071135520.29517@monopod.intra.ispras.ru>
On 08/07/2017 02:42 AM, Alexander Monakov wrote:
> On Sat, 5 Aug 2017, Richard Sandiford wrote:
>> It would be simpler to test whether targetm.gen_mem_thread_fence
>> returns NULL.
>>
>> This feels a bit hacky though. Checking whether a generator produced no
>> instructions is usually the test for whether the generator FAILed, which
>> should normally be treated as though the pattern wasn't defined to start
>> with. This is useful if the FAIL condition is too complex to put in the
>> define_expand/insn C condition.
>>
>> In those contexts, if a generator wants to succeed and generate no
>> instructions, it should emit a note instead. (Yes, it would be good
>> to have a nicer interface...)
>>
>> So IMO it's confusing to overload the empty sequence to mean something
>> else in this context, and it wouldn't work if a target does emit the kind
>> of "I didn't FAIL" note just mentioned.
>
> Thanks for the elucidation, I appreciate it.
>
>> FWIW, I agree with Jeff in the previous thread that (compared to this)
>> it would be more robust to make optabs.c emit the compile barrier
>> unconditionally and just leave the target to emit a machine barrier.
>
> OK, I've changed the patch accordingly. I've also factored out the
> is_mm_relaxed check in this iteration to simplify resulting code.
>
> PR target/80640
> * doc/md.texi (mem_thread_fence): Remove mention of mode. Rewrite.
> * optabs.c (expand_mem_thread_fence): Emit a compiler barrier when
> using targetm.gen_mem_thread_fence.
> testsuite/
> * gcc.dg/atomic/pr80640.c: New testcase.
THanks for your patience. OK for the trunk.
jeff