efriedma added inline comments.
================ Comment at: clang/lib/Basic/Targets/Sparc.cpp:224 + Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8"); + } } ---------------- ro wrote: > efriedma wrote: > > ro wrote: > > > efriedma wrote: > > > > ro wrote: > > > > > efriedma wrote: > > > > > > ro wrote: > > > > > > > efriedma wrote: > > > > > > > > This probably should be refactored so the target-independent > > > > > > > > code generates it based on MaxAtomicInlineWidth, instead of > > > > > > > > duplicating it for each target. But I guess you don't need to > > > > > > > > do that here. > > > > > > > > > > > > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check > > > > > > > > should only guard the definition of > > > > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8? > > > > > > > > This probably should be refactored so the target-independent > > > > > > > > code generates it based on MaxAtomicInlineWidth, instead of > > > > > > > > duplicating it for each target. But I guess you don't need to > > > > > > > > do that here. > > > > > > > > > > > > > > Good: one issue at a time ;-) > > > > > > > > > > > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check > > > > > > > > should only guard the definition of > > > > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8? > > > > > > > > > > > > > > I don't think so: at least `gcc` defines none of the four with > > > > > > > `-m32 -mcpu=v8` and all with `-m32 -mcpu=v9`. > > > > > > This code, the code that sets MaxAtomicInlineWidth, and the code > > > > > > inSPARCISelLowering.cpp that calls > > > > > > setMaxAtomicSizeInBitsSupported() all need to agree about the > > > > > > supported atomic operations. > > > > > > > > > > > > I guess the current setting of MaxAtomicInlineWidth is wrong? > > > > > I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while > > > > > `clang-11 -m32 -mcpu=v9` doesn't. > > > > Oh, hmm, it looks like the backend's support for 32-bit v9 is really > > > > limited; we basically generate v8 code, with a couple limited > > > > exceptions. Probably okay to make clang assume 64-bit atomics are > > > > actually supported, even if we don't inline the implementation at the > > > > moment; they should still behave correctly. > > > > > > > > I was more wondering about what we do for v8: we set > > > > MaxAtomicInlineWidth to 32, but I don't think it supports atomic > > > > cmpxchg at all. > > > I've now found [[http://temlib.org/pub/SparcStation/Standards/V8plus.pdf > > > | The V8+ Technical Specification ]]. I've not checked how far LLVM > > > makes use of that, though (gcc seems to be pretty extensive, and it > > > certainly makes use of `casx` for v8plus). > > > > > > I'm not really clear on the semantics of `MaxAtomicInlineWidth`: > > > `TargetInfo.h`'s description of `getMaxAtomicInlineWidth` only states > > > ``` > > > /// Return the maximum width lock-free atomic operation which can be > > > /// inlined given the supported features of the given target. > > > ``` > > > which would be satisfied given that **some** 32-bit atomic ops are > > > inlined for v8. > > > > > > > > The definition of C atomic operations requires that we only expose > > lock-free atomic operations on targets that have a lock-free cmpxchg. This > > is necessary to allow the implementation in libatomic to work: even if an > > operation is "atomic", it wouldn't correctly honor the libatomic locks. > > > > Note that the dynamic component of libatomic allows using lockfree > > operations in a "v8plus" environment. The libatomic implementation should > > dynamically check whether the CPU supports casx, and use lock-free > > operations if it does. > Honestly, I don't see this as my job, though: the issue is pre-existing, it > doesn't affect any of my targets and I see that GCC's libatomic forces > `-mcpu=v9` for the 32-bit sparc library. If you don't want to touch it, please leave a FIXME so the next person looking at this code has a reference. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86621/new/ https://reviews.llvm.org/D86621 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits