From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9156 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.gcc.devel Subject: SH runtime switchable atomics - proposed design Date: Tue, 19 Jan 2016 15:28:52 -0500 Message-ID: <20160119202851.GA18720@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1453235361 10811 80.91.229.3 (19 Jan 2016 20:29:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 20:29:21 +0000 (UTC) Cc: Oleg Endo , musl@lists.openwall.com To: gcc@gcc.gnu.org Original-X-From: musl-return-9169-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 19 21:29:20 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aLctz-0002pZ-VQ for gllmg-musl@m.gmane.org; Tue, 19 Jan 2016 21:29:20 +0100 Original-Received: (qmail 24560 invoked by uid 550); 19 Jan 2016 20:29:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24523 invoked from network); 19 Jan 2016 20:29:12 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9156 gmane.comp.gcc.devel:142264 Archived-At: 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