Re: Refactoring atomics as llsc?

[Alexander Monakov <amonakov@ispras.ru>]

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.

Alexander