Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 Jan 2016 15:28:52 -0500
From: Rich Felker <dalias@...c.org>
To: gcc@....gnu.org
Cc: Oleg Endo <oleg.endo@...nline.de>, musl@...ts.openwall.com
Subject: SH runtime switchable atomics - proposed design

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.