From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7735 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Refactoring atomics as llsc? Date: Thu, 21 May 2015 13:07:27 -0400 Message-ID: <20150521170727.GE17573@brightrain.aerifal.cx> References: <20150520051108.GA28347@brightrain.aerifal.cx> <20150521041237.GC17573@brightrain.aerifal.cx> <20150521120611.GO11258@port70.net> 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 1432228068 10580 80.91.229.3 (21 May 2015 17:07:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2015 17:07:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7747-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 21 19:07:43 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 1YvTwc-00059x-Tn for gllmg-musl@m.gmane.org; Thu, 21 May 2015 19:07:43 +0200 Original-Received: (qmail 11580 invoked by uid 550); 21 May 2015 17:07:41 -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 11562 invoked from network); 21 May 2015 17:07:40 -0000 Content-Disposition: inline In-Reply-To: <20150521120611.GO11258@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7735 Archived-At: On Thu, May 21, 2015 at 02:06:12PM +0200, Szabolcs Nagy wrote: > > 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? By default asm is pure. This is so you can write things like fancy arithmetic operations in asm, and in as sense it's the whole point of having fine-grained input and output constraints. Use of asm volatile, or input constraints referring to memory ("m" type, not just "r" type that happen to contain a memory address) that may have been clobbered, make it non-pure. > (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) I think it has some basic heuristics, but it won't necessarily keep it in a register anyway; it might spill to stack. That's reloadable in one instruction and should always be cached so it "should" always be at least as fast or faster than the asm. Rich