Hi,
Thank you for your comments.
> ..."stdbar" should never be generated since #StoreStore is implied by
TSO.
I missed that #StoreStore is never generated for TSO, so I'm removing
that pattern.
> OK, thanks. Does this result in a significance performance gain?
stb seems to be at least twice as fast as ldstub.
> I think that only the membar_storeload_leon3 pattern is necessary.
The full barrier pattern membar_leon3 also gets generated so I think
that one should be kept also.
I'm changing the pattern type to "store" and the condition on the
original patterns to "&& !TARGET_LEON3" and resubmitting the patch.
On 2014-07-10 11:37, Eric Botcazou wrote:
The memory barriers generated for SPARC are targeting the weakest memory
model allowed for SPARC.
That's not quite true, they are targeting the sparc_memory_model, which is the
memory model selected for the architecture/OS pair by default and which can be
overridden by the user with -mmemory-model=[default|rmo|pso|tso|sc].
The LEON3/4 SPARC processors are using a stronger memory model and thus have
less requirements on the memory barriers.
My understanding is that they use TSO, in which case...
For LEON3/4, StoreStore is compiler-only, instead of "stbar",
..."stdbar" should never be generated since #StoreStore is implied by TSO.
and StoreLoad can be achieved with a normal byte write "stb", instead of
an atomic byte read-write "ldstub".
OK, thanks. Does this result in a significance performance gain?
The provided patch changes the previously mentioned memory barriers for
TARGET_LEON3.
I think that only the membar_storeload_leon3 pattern is necessary. Couple of
more nits: the new pattern is not "multi", it's "store" and you need to add:
&& !TARGET_LEON3
to the original membar_storeload since TARGET_LEON3 is also TARGET_V8.
--
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758665
ceder...@gaisler.com
www.Aeroflex.com/Gaisler
