-
Notifications
You must be signed in to change notification settings - Fork 15.2k
[GlobalIsel] Add failure memory order to LegalityQuery (NFC) #162284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
@llvm/pr-subscribers-llvm-globalisel, the bot seems to have trouble, so pinging manually |
MemDesc(LLT MemoryTy, uint64_t AlignInBits, AtomicOrdering Ordering) | ||
: MemoryTy(MemoryTy), AlignInBits(AlignInBits), Ordering(Ordering) {} | ||
MemDesc(LLT MemoryTy, uint64_t AlignInBits, AtomicOrdering Ordering, | ||
AtomicOrdering FailureOrdering) |
There was a problem hiding this comment.
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.
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.
…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.
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 toLegalityQuery::MemDesc
, it is only set forcmpxchg
instructions, otherwise it isNotAtomic
. I didn't renameOrdering
toSuccessOrdering
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.