From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7736 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:08:23 -0400 Message-ID: <20150521170823.GF17573@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 1432228124 11475 80.91.229.3 (21 May 2015 17:08:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2015 17:08:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7748-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 21 19:08: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 1YvTxb-0005nH-CI for gllmg-musl@m.gmane.org; Thu, 21 May 2015 19:08:43 +0200 Original-Received: (qmail 13444 invoked by uid 550); 21 May 2015 17:08:38 -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 12267 invoked from network); 21 May 2015 17:08:35 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7736 Archived-At: On Thu, May 21, 2015 at 03:21:21PM +0300, Alexander Monakov wrote: > On Thu, 21 May 2015, Szabolcs Nagy wrote: > > > 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? > > The asm is not volatile, so the compiler can use its constraints to move it > like any other instruction. In this case there's only one input and output > register, and no clobbers. > > > (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) > > While obviously any sort of exact cost can not be known, GCC uses the line > count of the asm, iirc, as an estimation of the number of instructions. Interesting. So can you use ; instead of \n for semantic purposes controlling GCC's decision making? ;-) Rich