Re: ldcw inline assembler patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > diff --git a/include/asm-parisc/system.h b/include/asm-parisc/system.h
> > index ee80c92..4752684 100644
> > --- a/include/asm-parisc/system.h
> > +++ b/include/asm-parisc/system.h
> > @@ -168,8 +168,9 @@ static inline void set_eiem(unsigned long val)
> >  /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*.  */
> >  #define __ldcw(a) ({                                           \
> >        unsigned __ret;                                         \
> > -       __asm__ __volatile__(__LDCW " 0(%1),%0"                 \
> > -               : "=r" (__ret) : "r" (a));                      \
> > +       __asm__ __volatile__(__LDCW " 0(%2),%0"                 \
> > +                       : "=r" (__ret), "=m" (*(a))             \
> > +                       : "r" (a), "m" (*(a))   );              \
> >        __ret;                                                  \
> >  })
> 
> You don't want to do that, the compiler might hold "=m" (*(a)) in a
> temporary memory location.
> 
> e.g.
> temp_mem = *a;
> reg2 = &temp_mem;
> ... operation ...
> *a = temp_mem;

The operation uses "a" not "reg2".  Listing *a as written in the
asm should stop the compiler from caching *a in temp_mem.

I don't believe the compiler ever caches values in "memory".  However,
it does cache memory values in registers.  So, we need to tell GCC not
to cache *a in a register.  This can be done either by explicitly
listing the affected locations or by clobbering all memory.

I believe using the volatile keyword and a memory clobber is ok but
overkill.  Explicitly listing the affected memory as suggested by
Helge appears to be the way to go.  There is an example of this in
the GCC manual.

I also believe we can use the "+m" constraint so that *a doesn't need
to be listed twice.

It might be possible to remove the volatile keyword when the affected
memory is explicitly listed.  However, I doubt there are any situations
where the asm can be optimized away.

Dave
-- 
J. David Anglin                                  dave.anglin@xxxxxxxxxxxxxx
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux