Remove obsolete MB barrier for LKMM store

[hernanponcedeleon]

The removed code became obsolete after #893

[ThomasHaas]

LGTM. Is this the only remaining instance of obsolete barriers?

[hernanponcedeleon]

I just noticed there is one more in the Instrinsics class.

Strictly speaking, if we want to follow to the dot what herd+lkmm do, we need to add the extra barrier.

However, I would go with deviating from them (I am pretty sure the patch from Jonas could have also simplified the .bell file) and simplify our code. I would just need to fix our LKMM compilation.

[ThomasHaas]

I have no problem deviating from herd :). The only disadvantage with getting rid of all the barriers is that we do not support the old LKMM, but I'm not too keen to maintain both old and new compilation schemes for Linux.

P.S. I still find it quite annoying that we respect herd's precedence ordering for a;b \ c which any sane human would parse as (a;b) \ c and not a;(b \ c) :).

[hernanponcedeleon]

I have no problem deviating from herd :). The only disadvantage with getting rid of all the barriers is that we do not support the old LKMM, but I'm not too keen to maintain both old and new compilation schemes for Linux.

We stopped supporting the old LKMM as soon as we merged #893. While this PR removes the barriers on mb_store, that ne already did it for mb_rmw.

[ThomasHaas]

I have no problem deviating from herd :). The only disadvantage with getting rid of all the barriers is that we do not support the old LKMM, but I'm not too keen to maintain both old and new compilation schemes for Linux.

We stopped supporting the old LKMM as soon as we merged #893. While this PR removes the barriers on mb_store, that ne already did it for mb_rmw.

I know, my statement was more general. If you added a "compile to old LKMM" option and added the barrier in mb_rmw back, we might have been able to support both versions. The changes in this PR just confirm that there is no intention in supporting the old LKMM, which is fine with me.