Re: Refactoring atomics as llsc?

[Rich Felker <dalias@libc.org>]

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