-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[SPIRV][RFC] Rework / extend support for memory scopes #106429
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
Changes from 22 commits
d41faf6
757e119
af1a416
0cb89f6
11162b0
13f83ac
fe68593
e466a56
734630a
1637876
1d3fedb
440a0ef
daa76c3
25378a7
fc422b1
b6fd508
79acf40
bc712a3
e984939
ced6877
ec0eb50
8621e36
9f87c0f
e2f72fb
96a79e7
75776cc
92f739c
2cb4b46
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -766,8 +766,19 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr *Expr, Address Dest, | |
// LLVM atomic instructions always have synch scope. If clang atomic | ||
// expression has no scope operand, use default LLVM synch scope. | ||
if (!ScopeModel) { | ||
llvm::SyncScope::ID SS; | ||
if (CGF.getLangOpts().OpenCL) | ||
// OpenCL approach is: "The functions that do not have memory_scope | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Which flavor of atomic operations does this function correspond to? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the primary entry point for Atomic emission, so things like the Clang builtins (which do not carry scopes) would end up here. |
||
// argument have the same semantics as the corresponding functions with | ||
// the memory_scope argument set to memory_scope_device." See ref.: | ||
// https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#atomic-functions | ||
SS = CGF.getTargetHooks().getLLVMSyncScopeID(CGF.getLangOpts(), | ||
AlexVlx marked this conversation as resolved.
Show resolved
Hide resolved
|
||
SyncScope::OpenCLDevice, | ||
Order, CGF.getLLVMContext()); | ||
else | ||
SS = llvm::SyncScope::System; | ||
EmitAtomicOp(CGF, Expr, Dest, Ptr, Val1, Val2, IsWeak, FailureOrder, Size, | ||
Order, CGF.CGM.getLLVMContext().getOrInsertSyncScopeID("")); | ||
Order, SS); | ||
return; | ||
} | ||
|
||
|
Large diffs are not rendered by default.
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.
Isn't there a 64-bit atomic extension? How are extensions supposed to work here?
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'm assuming that the SPIRV32 target exists for cases where the
Int64
capability is never enabled, but it would probably be useful to have that assumption checked. For SPIR-V the model for extensions / capabilities in LLVM seems to be push i.e. extensions get enabled / checked iff a feature requiring the extension / capability is encountered when translating (legacy) / lowering (the experimental BE). FWIW, my reading of the SPIR-V spec is that theInt64
capability is core.