On Tue, May 15, 2018 at 08:11:36PM +0200, Peter Zijlstra wrote:
> On Tue, May 15, 2018 at 06:53:08PM +0100, Mark Rutland wrote:
> > On Tue, May 15, 2018 at 07:10:21PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 15, 2018 at 04:43:33PM +0100, Mark Rutland wrote:
> > > > I *think* the table can encode enough info to generate atomic-long.h,
> > > > atomic-instrumented.h, and the atomic.h ordering fallbacks. I'll need to
> > > > flesh out the table and check that we don't end up clashing with
> > > > some of the regular fallbacks.
> > > 
> > > Yes, details details ;-)
> > > 
> > > > # name  meta    args...
> > > > #
> > > > # Where meta contains a string of:
> > > > # * B - bool: returns bool, fully ordered
> > > > # * V - void: returns void, fully ordered
> > > 
> > > void retuns are relaxed
> > 
> > How about:
> > 
> >   V - void: returns void, no ordering variants (implicitly relaxed)
> 
> Works for me.
> 
> > > > # * I - int: returns base type, all orderings
> > > > # * R - return: returns base type, all orderings
> > > > # * F - fetch: returns base type, all orderings
> > > > # * T - try: returns bool, all orderings
> > > 
> > > Little more verbose than mine, I think we can get there with X and XB
> > > instead of I and T, but whatever :-)
> > 
> > Mhmm. I found it easier to do switch-like things this way, but it works
> > regardless.
> 
> I'm a minimalist, but yeah whatever ;-)
> 
> > > > # Where args contains list of type[:name], where type is:
> > > > # * v - pointer to atomic base type (atomic or atomic64)
> > > > # * i - base type (int or long)
> > > > # * I - pointer to base type (int or long)
> > > > #
> > > > add             VRF     i       v
> > > > sub             VRF     i       v
> > > > inc             VRF     v
> > > > dec             VRF     v
> > > > or              VF      i       v
> > > > and             VF      i       v
> > > > andnot          VF      i       v
> > > > xor             VF      i       v
> > > > xchg            I       v       i
> > > > cmpxchg         I       v       i:old   i:new
> > > > try_cmpxchg     T       v       I:old   i:new
> > > > add_and_test    B       i       v
> > > > sub_and_test    B       i       v
> > > > dec_and_test    B       v
> > > > inc_and_test    B       v
> 
> we might also want:
> 
> set           V       v       i
> set_release   V       v       i
> read          I       v
> read_acquire  I       v

Indeed!

I concurrently fiddled with this and came to the below. I special-cased
set and read for the purpose of preserving the acquire/release semantics
in the meta table, but either way works.

----
# name  meta    args...
#
# Where meta contains a string of variants to generate.
# Upper-case implies _{acquire,release,relaxed} variants.
# Valid meta values are:
# * B/b - bool: returns bool
# * v   - void: returns void
# * I/i - int: returns base type
# * R   - return: returns base type (has _return variants)
# * F   - fetch: returns base type (has fetch_ variants)
# * l   - load: returns base type (has _acquire order variant)
# * s   - store: returns void (has _release order variant)
#
# Where args contains list of type[:name], where type is:
# * cv  - const pointer to atomic base type (atomic_t/atomic64_t/atomic_long_t)
# * v   - pointer to atomic base type (atomic_t/atomic64_t/atomic_long_t)
# * i   - base type (int/s64/long)
# * I   - pointer to base type (int/s64/long)
#
read            l       cv
set             s       v       i
add             vRF     i       v
sub             vRF     i       v
inc             vRF     v
dec             vRF     v
and             vF      i       v
andnot          vF      i       v
or              vF      i       v
xor             vF      i       v
xchg            I       v       i
cmpxchg         I       v       i:old   i:new
try_cmpxchg     B       v       I:old   i:new
sub_and_test    b       i       v
dec_and_test    b       v
inc_and_test    b       v
add_negative    i       i       v
add_unless      i       v       i:a     i:u
inc_not_zero    i       v
----

... which seems to be sufficient to give me a working atomic-long.h
using [1,2].

I have *most* of the atomic.h ordering variant generation, and most of
atomic-instrumented.h, modulo a few special cases to be handled.

I'm also not sure which functions are intended to be mandatory. I had
hoped I could just wrap every atomic_foo in an ifdef, but not all arches
have a #define for all functions, so that needs to be handled somehow.

Thanks,
Mark.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=atomics/generated&id=6b44ecd77dbb7c3e518260d2e223a29c64c85740
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=atomics/generated&id=432d8259040a67b7234c869c9298d042515958a2

Reply via email to