[RESEND RFC PATCH v2 1/6] riscv/cmpxchg: Deduplicate cmpxchg() asm functions

[Leonardo Bras Soares Passos]

On Tue, Mar 21, 2023 at 9:45 PM Andrea Parri <parri.andrea at gmail.com> wrote:
>
> On Tue, Mar 21, 2023 at 04:42:44AM -0300, Leonardo Bras wrote:
> > In this header every cmpxchg define (_relaxed, _acquire, _release,
> > vanilla) contain it's own asm file, both for 4-byte variables an 8-byte
> > variables, on a total of 8 versions of mostly the same asm.
> >
> > This is usually bad, as it means any change may be done in up to 8
> > different places.
> >
> > Unify those versions by creating a new define with enough parameters to
> > generate any version of the previous 8.
> >
> > (This did not cause any change in generated asm)
> >
> > Signed-off-by: Leonardo Bras <leobras at redhat.com>
> > ---
> >  arch/riscv/include/asm/cmpxchg.h | 102 ++++++++-----------------------
> >  1 file changed, 24 insertions(+), 78 deletions(-)
>
> Diff looks nice,

Hello Andrea, thanks for reviewing!


> > +#define ___cmpxchg(lr_sfx, sc_sfx, prepend, append)                  \
> > +{                                                                    \
> > +     __asm__ __volatile__ (                                          \
> > +             prepend                                                 \
> > +             "0:     lr" lr_sfx " %0, %2\n"                          \
> > +             "       bne  %0, %z3, 1f\n"                             \
> > +             "       sc" sc_sfx " %1, %z4, %2\n"                     \
> > +             "       bnez %1, 0b\n"                                  \
> > +             append                                                  \
> > +             "1:\n"                                                  \
> > +             : "=&r" (__ret), "=&r" (__rc), "+A" (*__ptr)            \
> > +             : "rJ" ((long)__old), "rJ" (__new)                      \
> > +             : "memory");                                            \
> > +}
>
> Though I'm not really a fan of macros depending on local variables with
> "magic" names, can this be avoided?

You mean __ret, __rc, __ptr, __old and __new ?
If so, yes, we could add them to the macro signature, but it would
become quite big with not much to gain. To reduce impact it could be
something like:

+#define ___cmpxchg(lr_sfx, sc_sfx, prepend, append, ret, r, p, o, n)

Is this a possible fix?
>
> Thanks,
>   Andrea
>

Thank you!
Leo