yxsamliu wrote: > > > The underlying implementation is a string literal in the LLVM syncscope > > > argument, but the problem is that this isn't standardized at all and > > > varies between backends potentially > > > > > > We don't have to use the same set of strings as syncscope if that doesn't > > make sense. > > I don't think there's much of a point to making them strings if it's not > directly invoking the syncscope name for the backend. Realistically as long > as we give them descriptive names we can just ignore ones that don't apply on > various targets. Like right now you can use these scoped variants in x64 code > but it has no effect. Either that or we could use logic to go to the next > heirarchy level that makes sense. As always, naming stuff is hard.
There is another reason that string syncscope is not favored is that some languages uses enums for syncscope in their own atomic APIs, e.g. OpenCL. Currently clang is able to define macros that matches the language's enum for syncscope so that implementing OpenCL atomic API is just a trivial mapping to clang's builtin. However, if clang's atomic builtin uses string for syncscope, that would be quite inconvenient to use those builtin's to implement OpenCL's atomic API. https://github.com/llvm/llvm-project/pull/72280 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
