This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/3] optabs: ensure mem_thread_fence is a compiler barrier

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]