ro added inline comments.
================
Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+ Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+ }
}
----------------
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.
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
