Re: Refactoring atomics as llsc?

[Rich Felker <dalias@libc.org>]

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