Skip to content
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

Default semantics of syncscope("system") missing in the langref #123339

Open
vchuravy opened this issue Jan 17, 2025 · 0 comments
Open

Default semantics of syncscope("system") missing in the langref #123339

vchuravy opened this issue Jan 17, 2025 · 0 comments
Labels
documentation llvm Umbrella label for LLVM issues

Comments

@vchuravy
Copy link
Contributor

In multiple places throughout the llvm codebase, it is assumed that syncscope("system") is the default.

As an example, when an atomic operation is created with syncscope("system") printing it omits that syncscope.

case SyncScope::System:
break;

When creating an atomic load instruction without a syncscope specifiy it is assumed to be system

LoadInst::LoadInst(Type *Ty, Value *Ptr, const Twine &Name, bool isVolatile,
Align Align, InsertPosition InsertBef)
: LoadInst(Ty, Ptr, Name, isVolatile, Align, AtomicOrdering::NotAtomic,
SyncScope::System, InsertBef) {}

This default nature of system should be documented in the language reference, where currently only target-specific (e.g. what backends like AMDGPU have) and single-threaded exist.

A wrinkle is the PTX backend. PTX does mostly use NVVM intrinsics, but also some LLVM atomic operations.
Eventually, I would love to see a move away from the nvvm intrinsics and instead fully use the LLVM atomic operation,
but currently PTX does not handle syncscopes and thus "mistranslates" the syncscope("system") to the PTX syncscope device...

This essentially means that there is an ambiguity between syncscope("system") and the syncscope being left undefined.
I wanted to start work on supporting atomics with a syncscope argument in the PTX backend, but this conflict in defaults would potentially break users who have been emitting atomic operations on PTX. To be clear, it would be a performance issue and not a semantic one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation llvm Umbrella label for LLVM issues
Projects
None yet
Development

No branches or pull requests

3 participants