[webkit-dev] Data Memory Barrier ARMv6 question

[Filip Pizlo]

We should not use those helpers, especially in the JIT. It does not make sense for the JIT to emit calls to system functions when the user is expecting it to emit an instruction. If we cannot perfectly select the right barrier on a particular CPU, we should disable concurrency on that CPU. 

-Filip

> On Jul 5, 2017, at 8:41 AM, JF Bastien <jfbastien at apple.com> wrote:
> 
> On Linux you can do the following:
> ((void(*)())0xffff0fa0)();
> 
> That address contains a helper which does the “right” barrier, including if you’re not on an SMP system it’ll do nothing.
> 
> Details: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
> That file also lists other Linux helpers.
> 
> I think for ARMv6 it makes sense to use these helpers. AFAIK the mcr barrier instruction ins’t supported by all ARMv6 CPUs.
> 
> For ARMv7 and later, DMB ish is the right thing.
> 
> 
>> On Jul 3, 2017, at 17:19, Caio Lima <ticaiolima at gmail.com> wrote:
>> 
>> Hi all.
>> 
>> I'm working in this patch
>> (https://bugs.webkit.org/show_bug.cgi?id=172767) and Mark Lam raised
>> some questions about the data memory barrier (DMB for short) in ARMv6
>> using "mcr 15 ...". The point is that we are having divergences in ARM
>> official reference manual about the semantics of this instruction. We
>> have it discussed in the bug above and I would like to know if there
>> is somebody with stronger ARM background that could help us there and
>> then approve the patch to be committed.
>> 
>> I thanks in advance and best regards,
>> Caio Lima.
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170705/ea23a879/attachment.html>