http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065
--- Comment #4 from Zhangxi Tan <tanzhangxi at gmail dot com> 2011-08-14
01:30:33 UTC ---
I don't think this is an valid optimization.
There are only two memory models in SPARC32, TSO and PSO (not RMO in the 64-bit
v9). Both don't allow relaxing the read->write order, i.e. 'LD remap_barrier'
should always be executed before 'ST lock'.
This optimization violates the memory model, therefore should be prohibited.
In addition, I still(In reply to comment #2)
> > instruction 2C, clrb [%g1] corresponds to inline function 'spinlock_unlock'
> > *(volatile unsigned char*)lock = 0;
> >
> > This happens before the lock protected content 'remap_barrier++', i.e.
> >
> > 30: c6 00 a0 00 ld [ %g2 ], %g3
> > 34: 86 00 e0 01 inc %g3
> > 38: 81 c3 e0 08 retl
> > 3c: c6 20 a0 00 st %g3, [ %g2 ] ---> use the branch delay slot
> >
> > This is wrong and will cause serious lock issues under a multithreading
> > environment.
>
> On what grounds is this wrong exactly? The end of the code is equivalent to:
>
> volatile unsigned char lock;
> int remap_barrier;
>
> remap_barrier++;
> lock = 0;
>
> It is perfectly valid for an optimizing C compiler to swap the two lines.
>
> You want something like:
>
> static inline void spin_unlock(char *lock)
> {
> __asm__ __volatile__("stb %%g0, [%0]" : : "r" (lock) : "memory");
> }
