git
/
gcc
mirror of git://gcc.gnu.org/git/gcc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

retire mem_signal_fence pattern 

* 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.

From-SVN: r251597
This commit is contained in:
Alexander Monakov 2017-09-01 17:08:42 +03:00 committed by Alexander Monakov
parent 3ca3c6ef71
commit 44acb9ba2b
5 changed files with 13 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
gcc/ChangeLog
View File

@ -1,3 +1,11 @@
2017-09-01 Alexander Monakov <amonakov@ispras.ru>
* 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.
2017-09-01 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/81902

9
gcc/config/s390/s390.md
View File

@ -10084,15 +10084,6 @@
; memory barrier patterns.
;
(define_expand "mem_signal_fence"
[(match_operand:SI 0 "const_int_operand")] ;; model
""
{
/* The s390 memory model is strong enough not to require any
barrier in order to synchronize a thread with itself. */
DONE;
})
(define_expand "mem_thread_fence"
[(match_operand:SI 0 "const_int_operand")] ;; model
""

13
gcc/doc/md.texi
View File

@ -7059,19 +7059,6 @@ If this pattern is not defined, the compiler falls back to expanding the
@code{memory_barrier} pattern, then to emitting @code{__sync_synchronize}
library call, and finally to just placing a compiler memory barrier.
@cindex @code{mem_signal_fence@var{mode}} instruction pattern
@item @samp{mem_signal_fence@var{mode}}
This pattern emits code required to implement a signal fence with
memory model semantics. Operand 0 is the memory model to be used.
This pattern should impact the compiler optimizers the same way that
mem_signal_fence does, but it does not need to issue any barrier
instructions.
If this pattern is not specified, all memory models except
@code{__ATOMIC_RELAXED} will result in issuing a @code{sync_synchronize}
barrier pattern.
@cindex @code{get_thread_pointer@var{mode}} instruction pattern
@cindex @code{set_thread_pointer@var{mode}} instruction pattern
@item @samp{get_thread_pointer@var{mode}}

17
gcc/optabs.c
View File

@ -6318,22 +6318,15 @@ expand_mem_thread_fence (enum memmodel model)
expand_asm_memory_barrier ();
}
/* This routine will either emit the mem_signal_fence pattern or issue a
sync_synchronize to generate a fence for memory model MEMMODEL. */
/* Emit a signal fence with given memory model. */
void
expand_mem_signal_fence (enum memmodel model)
{
if (targetm.have_mem_signal_fence ())
emit_insn (targetm.gen_mem_signal_fence (GEN_INT (model)));
else if (!is_mm_relaxed (model))
{
/* By default targets are coherent between a thread and the signal
handler running on the same thread. Thus this really becomes a
compiler barrier, in that stores must not be sunk past
(or raised above) a given point. */
expand_asm_memory_barrier ();
}
/* No machine barrier is required to implement a signal fence, but
a compiler memory barrier must be issued, except for relaxed MM. */
if (!is_mm_relaxed (model))
expand_asm_memory_barrier ();
}
/* This function expands the atomic load operation:

1
gcc/target-insns.def
View File

@ -58,7 +58,6 @@ DEF_TARGET_INSN (indirect_jump, (rtx x0))
DEF_TARGET_INSN (insv, (rtx x0, rtx x1, rtx x2, rtx x3))
DEF_TARGET_INSN (jump, (rtx x0))
DEF_TARGET_INSN (load_multiple, (rtx x0, rtx x1, rtx x2))
DEF_TARGET_INSN (mem_signal_fence, (rtx x0))
DEF_TARGET_INSN (mem_thread_fence, (rtx x0))
DEF_TARGET_INSN (memory_barrier, (void))
DEF_TARGET_INSN (movstr, (rtx x0, rtx x1, rtx x2))