Rationale looks good. (Side note: RVA23 profile says Zabha will be mandatory in future RVA profiles)

Surely these belong in atomic_subword.h or similar? They're not at all specific to RISC-V, and other architectures lack various of these.

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

In D57379#1314780, @jrtc27 wrote:

Surely these belong in atomic_subword.h or similar? They're not at all specific to RISC-V, and other architectures lack various of these.

Yeah, I think maybe putting them in atomic_subword.h is a better choice. I will update tomorrow.

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Ah, I didn't actually consider the performance before.
I added these to simplify the KASAN porting. KASAN needs to intercept these defines, but riscv doesn't have these definitions, so adding them ensures the KASAN common code won't be polluted by arch-specific code.

In D57379#1314783, @zishun.yi.dev_gmail.com wrote:

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Ah, I didn't actually consider the performance before.
I added these to simplify the KASAN porting. KASAN needs to intercept these defines, but riscv doesn't have these definitions, so adding them ensures the KASAN common code won't be polluted by arch-specific code.

KASAN should just not intercept things that don't exist

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Just curious: do we have trampolines for sub-atomic operations at instruction level? Having them for Zabha or LDADD* would be great optimization opportunity.

In D57379#1314785, @minsoochoo0122_proton.me wrote:

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Just curious: do we have trampolines for sub-atomic operations at instruction level? Having them for Zabha or LDADD* would be great optimization opportunity.

I don't understand what your question means

In D57379#1314786, @jrtc27 wrote:

In D57379#1314785, @minsoochoo0122_proton.me wrote:

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Just curious: do we have trampolines for sub-atomic operations at instruction level? Having them for Zabha or LDADD* would be great optimization opportunity.

I don't understand what your question means

The code has todo for Zabha support. I guess this means there will be implementation in future

if (has_zabha) {
    AMOADD.{B,H};
} else {
    load and fcmpset;
}

Oh, I think I used the term "trampoline" incorrectly here. I meant branching based on detection of Zabha (or equivalent on other ISA).

Back to my original question: How can we achieve this "special path" so processors with Zabha don't have severe performance impact?

In D57379#1314791, @minsoochoo0122_proton.me wrote:

In D57379#1314786, @jrtc27 wrote:

In D57379#1314785, @minsoochoo0122_proton.me wrote:

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Just curious: do we have trampolines for sub-atomic operations at instruction level? Having them for Zabha or LDADD* would be great optimization opportunity.

I don't understand what your question means

The code has todo for Zabha support. I guess this means there will be implementation in future

if (has_zabha) {
    AMOADD.{B,H};
} else {
    load and fcmpset;
}

Oh, I think I used the term "trampoline" incorrectly here. I meant branching based on detection of Zabha (or equivalent on other ISA).

Back to my original question: How can we achieve this "special path" so processors with Zabha don't have severe performance impact?

Same as LSE on arm64

In D57379#1314792, @jrtc27 wrote:

In D57379#1314791, @minsoochoo0122_proton.me wrote:

Back to my original question: How can we achieve this "special path" so processors with Zabha don't have severe performance impact?

Same as LSE on arm64

Found it. Thanks:)

In D57379#1314784, @jrtc27 wrote:

In D57379#1314783, @zishun.yi.dev_gmail.com wrote:

In D57379#1314781, @jrtc27 wrote:

Having said that, what is the use case you have for these? Generally speaking you shouldn't be using sub-word atomics unless absolutely needed, since performance will be worse.

Ah, I didn't actually consider the performance before.
I added these to simplify the KASAN porting. KASAN needs to intercept these defines, but riscv doesn't have these definitions, so adding them ensures the KASAN common code won't be polluted by arch-specific code.

KASAN should just not intercept things that don't exist

Fair enough. I should fix the KASAN side instead of adding these to riscv.
Thanks, I will do it tomorrow.