[CIR][CIRGen] Support for builtin __atomic_thread_fence
#1287
Conversation
|
I have just created the ODS definition at the moment to be sure if this is the way to go. |
Rajveer100
force-pushed
the
atomic-thread_signal-fence
branch
from
969faf7 to
c2cc1a9
Compare
There was a problem hiding this comment.
Initial step looks good, some inline comments. Note that this PR should come with CIRGen and LLVM lowering support, I suggest you first handle a very simple case of the fence and mark all paths not currently support with llvm_unrecheable("NYI"), so that you can go about working in incremental PRs to complete this.
bcardosolopes
changed the title
__atomic_thread_fence__atomic_thread_fence
Rajveer100
force-pushed
the
atomic-thread_signal-fence
branch
from
c2cc1a9 to
e8758ac
Compare
|
We just went over a rebase against upstream, apologies for the churn but please update your branch for this PR and force-push! |
Resolves llvm#1274 Implements atomic thread fence synchronization primitive corresponding to `atomic.thread_fence` CIR.
Rajveer100
force-pushed
the
atomic-thread_signal-fence
branch
from
e8758ac to
ca75a57
Compare
| @@ -820,6 +821,16 @@ class CIRToLLVMAtomicFetchLowering | |||
| mlir::ConversionPatternRewriter &) const override; | |||
| }; | |||
|
|
|||
| // class CIRToLLVMAtomicFenceLowering | |||
There was a problem hiding this comment.
So far so good, time to add support for LLVM lowering as well, so we make sure the CIR operations contain all the info we need to lower to LLVM. You also need to add tests to this PR, see example in clang/test/CIR/CodeGen/abstract-cond.c.
There was a problem hiding this comment.
And I believe LLVM::FenceOp is what you need to lower to. For CIR::AtomicFence
| case Builtin::BI__c11_atomic_thread_fence: | ||
| case Builtin::BI__c11_atomic_signal_fence: | ||
| llvm_unreachable("BI__atomic_thread_fence like NYI"); | ||
| llvm_unreachable("BI__c11_atomic_thread_fence like NYI"); |
There was a problem hiding this comment.
From OG's code, it looks like that c11 cases have same implementation? could we have them supported as well? You don't have to, it's a nice to have.
There was a problem hiding this comment.
Sure, I was unsure if it would be the same so marked it as unreachable.
| : builder.getSIntNTy(cgf.getContext().getTypeSize(typ)); | ||
|
|
||
| auto orderingVal = | ||
| emitToInt(cgf, cgf.emitScalarExpr(expr->getArg(1)), typ, intType); |
There was a problem hiding this comment.
Sorry, I'm a bit lost here. looking at OG, and definition of builtin
The call expr should have only one argument, so what is this expr->getArg(1) about?
Also, it seems that memOrdering could be variable, in which case switch and blocks generated
The code added here seems only handling constant ordering case, which is totally fine to me, but we need to NYI or missing feature for the variable situation.
| @@ -820,6 +821,16 @@ class CIRToLLVMAtomicFetchLowering | |||
| mlir::ConversionPatternRewriter &) const override; | |||
| }; | |||
|
|
|||
| // class CIRToLLVMAtomicFenceLowering | |||
There was a problem hiding this comment.
And I believe LLVM::FenceOp is what you need to lower to. For CIR::AtomicFence
Fix #1274
Implements atomic thread fence synchronization primitive corresponding to
atomic.thread_fenceCIR.