> LEON3 has a store buffer of length 1, so an additional store is required
> to be sure that the one preceding it has been written to memory. I am
> not familiar enough with the internals of gcc to pick the optimal place
> to encode this behavior, so any suggestions from you are appreciated :)
OK,
LEON3 has a store buffer of length 1, so an additional store is required
to be sure that the one preceding it has been written to memory. I am
not familiar enough with the internals of gcc to pick the optimal place
to encode this behavior, so any suggestions from you are appreciated :)
On 2014
> That was an error on my side. The wrong memory model had gotten cached
> in a generated make script. Lets drop membar_leon3 also then :)
Fine with me but, on second thoughts, if a mere "stb" is a #StoreLoad memory
barrier for LEON3, doesn't this simply mean that the memory model of the LEON3
i
That was an error on my side. The wrong memory model had gotten cached
in a generated make script. Lets drop membar_leon3 also then :)
On 2014-07-11 11:15, Eric Botcazou wrote:
The full barrier pattern membar_leon3 also gets generated so I think
that one should be kept also.
Do you have a tes
> The full barrier pattern membar_leon3 also gets generated so I think
> that one should be kept also.
Do you have a testcase? membar is generated by sparc_emit_membar_for_model
and, for the TSO model of LEON3, implied = StoreStore | LoadLoad | LoadStore
so mm can only be StoreLoad, which means
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 tw
> 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
Hello,
The memory barriers generated for SPARC are targeting the weakest memory
model allowed for SPARC. The LEON3/4 SPARC processors are using a
stronger memory model and thus have less requirements on the memory
barriers. For LEON3/4, StoreStore is compiler-only, instead of "stbar",
and Sto
