mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: gcc@gcc.gnu.org
Cc: Oleg Endo <oleg.endo@t-online.de>, musl@lists.openwall.com
Subject: SH runtime switchable atomics - proposed design
Date: Tue, 19 Jan 2016 15:28:52 -0500	[thread overview]
Message-ID: <20160119202851.GA18720@brightrain.aerifal.cx> (raw)

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:

Inputs:
- R0: Memory address to operate on
- R1: Address of implementation function, loaded from a global
- R2: Comparison value
- R3: Value to set on success

Outputs:
- 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:

	rts
	 cas.l r2,r3,@r0

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
and PR.

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.

Rich


             reply	other threads:[~2016-01-19 20:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 20:28 Rich Felker [this message]
2016-01-19 20:51 ` Rich Felker
2016-01-20 23:08 ` Oleg Endo
2016-01-21  1:22   ` Rich Felker
2016-01-21 11:22     ` Torvald Riegel
2016-01-21 11:32     ` Oleg Endo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160119202851.GA18720@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=gcc@gcc.gnu.org \
    --cc=musl@lists.openwall.com \
    --cc=oleg.endo@t-online.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).