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
