public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jinyang He <hejinyang@loongson.cn>
To: Xi Ruoyao <xry111@xry111.site>,
	Chenghua Xu <xuchenghua@loongson.cn>,
	Lulu Cheng <chenglulu@loongson.cn>
Cc: Weining Lu <luweining@loongson.cn>, Xing Li <lixing@loongson.cn>,
	yala <zhaojunchao@loongson.cn>, Peng Fan <fanpeng@loongson.cn>,
	gcc-patches@gcc.gnu.org, Huang Pei <huangpei@loongson.cn>
Subject: Re: [PATCH] LoongArch: Fix atomic_exchange make comparison and may jump out
Date: Thu, 17 Nov 2022 10:55:50 +0800	[thread overview]
Message-ID: <be3a13ca-fcb7-16a9-cb20-6c5743a7894e@loongson.cn> (raw)
In-Reply-To: <f2e58619-359e-7c57-7ba7-4aec2a1a2c1c@loongson.cn>

On 2022/11/17 上午9:39, Jinyang He wrote:

> On 2022/11/16 下午7:46, Xi Ruoyao wrote:
>
>> On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
>>
>>>>> +  return "%G6\\n\\t"
>>>>> +        "1:\\n\\t"
>>>>> +        "ll.<amo>\\t%0,%1\\n\\t"
>>>>> +        "and\\t%7,%0,%z3\\n\\t"
>>>>> +        "or%i5\\t%7,%7,%5\\n\\t"
>>>>> +        "sc.<amo>\\t%7,%1\\n\\t"
>>>>> +        "beqz\\t%7,1b\\n\\t";
>>>> Do we need a "dbar 0x700" after beqz?
>>>>
>>>> /* snip */
>>> That's worth discussing. Actually I don't see any dbar hint definition
>>> like 0x700 in the manual right now.
>>> Besides, I think what should be provided here is a relaxed version. And
>>> whether the barrier exsit or not is depend on the specific 
>>> memory_order.
>> It's not related to memory order, but for a hardware issue workaround.
>> Jiaxun told me (via LKML):
>>
>>     I had checked with Loongson guys and they confirmed that the
>>     workaround still needs to be applied to latest 3A4000 processors,
>>     including 3A4000 for MIPS and 3A5000 for LoongArch.
>>         Though, the reason behind the workaround varies with the 
>> evaluation
>>     of their uArch, for GS464V based core, barrier is required as the
>>     uArch design allows regular load to be reordered after an atomic
>>     linked load, and that would break assumption of compiler atomic
>>     constraints.
>
> That certainly seems to be needed, but before or after. It's beyond my
> recognition and cc huangpei@loongson.cn for help.


Pei told me the ll-sc works at present like follows,

uArch like:
   ll -> (ll.dbar ll.ld_atomic)
   sc -> (sc.dbar sc.st_atomic)

exchange:
ll.dbar
<---------------------------+
ll.ld_atomic $rd            |
...(no jmp)                 |
sc.dbar                     |
sc.st_stomic $rd            |
ld $rj -can-not-emit-at-----+

The load $rj can not emit between ll.dbar and ll.ld_atomic because the 
sc.dbar barrier it.


compare and exchange:
ll.dbar
<-----------------------+
ll.ld_atomic $rd        |
...(jmp) ---------------+------+
sc.dbar                 |      |
sc.st_stomic $rd        |      |
                         |   <--+
ld $rj -may-emit-at-----+

Jumping out ll-sc may lead loading $rj emit between ll.dbar and ll.atomic.


Thus, exchange not need dbar.


>
>
>>
>> Without these dbar instructions I'd got random test failures in GCC
>> libgomp test suite.

Which test suite?


>>
>> We use a non-zero hint here because it is treated exactly same as zero
>> in 3A5000, and the future LoongArch processors can fix the issue and
>> ignore the dbar 0x700 instruction.
> Thanks, it's a nice workaround.


  reply	other threads:[~2022-11-17  2:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15 13:03 Jinyang He
2022-11-15 14:21 ` Xi Ruoyao
2022-11-16  2:11   ` Jinyang He
2022-11-16 11:46     ` Xi Ruoyao
2022-11-17  1:39       ` Jinyang He
2022-11-17  2:55         ` Jinyang He [this message]
2022-11-17  3:38           ` Xi Ruoyao
2022-11-17  3:46             ` Jinyang He
2022-11-17  5:56               ` Xi Ruoyao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be3a13ca-fcb7-16a9-cb20-6c5743a7894e@loongson.cn \
    --to=hejinyang@loongson.cn \
    --cc=chenglulu@loongson.cn \
    --cc=fanpeng@loongson.cn \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=huangpei@loongson.cn \
    --cc=lixing@loongson.cn \
    --cc=luweining@loongson.cn \
    --cc=xry111@xry111.site \
    --cc=xuchenghua@loongson.cn \
    --cc=zhaojunchao@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).