Skip to content

Conversation

Maetveis
Copy link
Contributor

@Maetveis Maetveis commented Oct 7, 2025

The cmpxchg instruction has two memory orders, one for success and one for failure.
Prior to this patch LegalityQuery only exposed a single memory order, that of the success case. This meant that it was not generally possible to legalize cmpxchg instructions based on their memory orders.

Add a FailureOrdering field to LegalityQuery::MemDesc, it is only set for cmpxchg instructions, otherwise it is NotAtomic. I didn't rename Ordering to SuccessOrdering or similar to avoid breaking changes for out of tree targets.
The new field does not increase sizeof(MemDesc), it falls into previous padding bits due to alignment, so I'd expect there to be no performance impact for this change.

Verified via check-llvm in build with AMDGPU, AArch64, and X86 targets enabled.

The `cmpxchg` instruction has two memory orders, one for success and one for
failure.
Prior to this patch LegalityQuery only exposed a single memory order,
that of the success case. This meant that it was not generally possible
to legalize `cmpxchg` instructions based on their memory orders.

Add a `FailureOrdering` field to `LegalityQuery::MemDesc`, it is only
set for `cmpxchg` instructions, otherwise it is `NotAtomic`.
I didn't rename `Ordering` to `SuccessOrdering` or similar to avoid
breaking changes for out of tree targets.

Verified via check-llvm in build with AMDGPU, AArch64, and X86 targets.
@Maetveis
Copy link
Contributor Author

Maetveis commented Oct 7, 2025

@llvm/pr-subscribers-llvm-globalisel, the bot seems to have trouble, so pinging manually

@Maetveis Maetveis requested review from arsenm and davemgreen October 7, 2025 13:52
MemDesc(LLT MemoryTy, uint64_t AlignInBits, AtomicOrdering Ordering)
: MemoryTy(MemoryTy), AlignInBits(AlignInBits), Ordering(Ordering) {}
MemDesc(LLT MemoryTy, uint64_t AlignInBits, AtomicOrdering Ordering,
AtomicOrdering FailureOrdering)
Copy link
Contributor Author

@Maetveis Maetveis Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of adding a default value of AtomicOrdering::NotAtomic to FailureOrdering, but I decided that being explicit might be better.
I don't feel strongly about this though. Without the default its possible this pr breaks downstream forks.

@Maetveis Maetveis merged commit cc1ca59 into llvm:main Oct 9, 2025
10 of 11 checks passed
@Maetveis Maetveis deleted the gisel-add-failure-memorder branch October 9, 2025 07:05
svkeerthy pushed a commit that referenced this pull request Oct 9, 2025
The `cmpxchg` instruction has two memory orders, one for success and one
for failure.
Prior to this patch `LegalityQuery` only exposed a single memory order,
that of the success case. This meant that it was not generally possible
to legalize `cmpxchg` instructions based on their memory orders.

Add a `FailureOrdering` field to `LegalityQuery::MemDesc`; it is only
set for `cmpxchg` instructions, otherwise it is `NotAtomic`. I didn't
rename `Ordering` to `SuccessOrdering` or similar to avoid breaking
changes for out of tree targets.
The new field does not increase `sizeof(MemDesc)`, it falls into
previous padding bits due to alignment, so I'd expect there to be no
performance impact for this change.

Verified no breakage via check-llvm in build with AMDGPU, AArch64, and X86 targets
enabled.
clingfei pushed a commit to clingfei/llvm-project that referenced this pull request Oct 10, 2025
…2284)

The `cmpxchg` instruction has two memory orders, one for success and one
for failure.
Prior to this patch `LegalityQuery` only exposed a single memory order,
that of the success case. This meant that it was not generally possible
to legalize `cmpxchg` instructions based on their memory orders.

Add a `FailureOrdering` field to `LegalityQuery::MemDesc`; it is only
set for `cmpxchg` instructions, otherwise it is `NotAtomic`. I didn't
rename `Ordering` to `SuccessOrdering` or similar to avoid breaking
changes for out of tree targets.
The new field does not increase `sizeof(MemDesc)`, it falls into
previous padding bits due to alignment, so I'd expect there to be no
performance impact for this change.

Verified no breakage via check-llvm in build with AMDGPU, AArch64, and X86 targets
enabled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants