From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7733 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Refactoring atomics as llsc? Date: Thu, 21 May 2015 14:06:12 +0200 Message-ID: <20150521120611.GO11258@port70.net> References: <20150520051108.GA28347@brightrain.aerifal.cx> <20150521041237.GC17573@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 1432209987 28362 80.91.229.3 (21 May 2015 12:06:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2015 12:06:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7745-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 21 14:06:27 2015 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 1YvPF4-0004vd-Su for gllmg-musl@m.gmane.org; Thu, 21 May 2015 14:06:26 +0200 Original-Received: (qmail 29755 invoked by uid 550); 21 May 2015 12:06:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29724 invoked from network); 21 May 2015 12:06:23 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20150521041237.GC17573@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7733 Archived-At: * Rich Felker [2015-05-21 00:12:37 -0400]: > This is coming along really well so far. Here's the ARMv7 code > generated for a sample external x_swap function that calls a_swap: > > x_swap: > mov r3, r0 > dmb ish > .L3: > ldrex r0, [r3] > strex r2,r1,[r3] > cmp r2, #0 > bne .L3 > dmb ish > bx lr > > The code that's producing this is the arm atomic_arch.h (so far only > supports inline atomics for v7+): > ... > #ifndef a_swap > #define a_swap a_swap > static inline int a_swap(volatile int *p, int v) > { > int old; > a_pre_llsc(); > do old = a_ll(p); > while (!a_sc(p, v)); > a_post_llsc(); > return old; > } > #endif > nice > Unfortunately there's a nasty snag: global objects like > need_fallback_a_swap, v6_compat, or barrier_func_ptr will be re-read > over and over in functions using atomics because the "memory" clobbers > in the asm invalidate any value the compiler may have cached. > > Fortunately, there seems to be a clean solution: load them via asm > that looks like > > static inline int v6_compat() { > int r; > __asm__ ( "..." : "=r"(r) ); > return r; > } > > where the "..." is asm to perform the load. Since this asm is not > volatile and has no inputs, it can be CSE'd and treated like an > attribute-const function. Strictly speaking this doesn't prevent > reordering to the very beginning of program execution, before the > runtime atomic selection is initialized, but I don't think that's a > serious practical concern. It's certainly not a concern with dynamic > linking since nothing can be reordered back into dynamic-linker-time, > and the atomics would be initialized there. For static-linking LTO > this may require some more thought for formal correctness. does gcc cse that? why is it guaranteed that r will be always the same? (and how can gcc know the cost of the asm? it seems to me that would be needed to determine if it's worth keeping r in a reg or just rerun the asm every time)