This is the mail archive of the
mailing list for the GCC project.
SH runtime switchable atomics - proposed design
- From: Rich Felker <dalias at libc dot org>
- To: gcc at gcc dot gnu dot org
- Cc: Oleg Endo <oleg dot endo at t-online dot de>, musl at lists dot openwall dot com
- Date: Tue, 19 Jan 2016 15:28:52 -0500
- Subject: SH runtime switchable atomics - proposed design
- Authentication-results: sourceware.org; auth=none
I've been working on the new version of runtime-selected SH atomics
for musl, and I think what I've got might be appropriate for GCC's
generated atomics too. I know Oleg was not very excited about doing
this on the gcc side from a cost/benefit perspective, but I think my
approach is actually preferable over inline atomics from a code size
perspective. It uses a single "cas" function with an "SFUNC" type ABI
(not standard calling convention) with the following constraints:
- R0: Memory address to operate on
- R1: Address of implementation function, loaded from a global
- R2: Comparison value
- R3: Value to set on success
- R3: Old value read, ==R2 iff cas succeeded.
Preserved: R0, R2.
Clobbered: R1, PR, T.
This call (performed from __asm__ for musl, but gcc would do it as SH
"SFUNC") is highly compact/convenient for inlining because it avoids
clobbering any of the argument registers that are likely to already be
in use by the caller, and it preserves the important values that are
likely to be reused after the cas operation.
For J2 and future J4, the function pointer just points to:
and the only costs vs an inline cas.l are loading the address of the
function (done in the caller; involves GOT access) and clobbering R1
This is still a draft design and the version in musl is subject to
change at any time since it's not a public API/ABI, but I think it
could turn into something useful to have on the gcc side with a
-matomic-model=libfunc option or similar. Other ABI considerations for
gcc use would be where to store the function pointer and how to
initialize it. To be reasonably efficient with FDPIC the caller needs
to be responsible for loading the function pointer (and it needs to
always point to code, not a function descriptor) so that the callee
does not need a GOT pointer passed in.