[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

["tanzhangxi at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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");
> }