[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

Rainer Orth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Sep 1 13:46:35 PDT 2020


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:
> > > 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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86621/new/

https://reviews.llvm.org/D86621



More information about the cfe-commits mailing list