[PATCH] D16614: Use "long long int" when checking whether atomics are supported.

[Joerg Sonnenberger via llvm-commits]

On Wed, Jan 27, 2016 at 01:25:28PM +0000, Daniel Sanders wrote:
> > -----Original Message-----
> > From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf
> > Of Vasileios Kalintiris via llvm-commits
> > Sent: 27 January 2016 10:37
> > To: Joerg Sonnenberger; llvm-commits at lists.llvm.org
> > Subject: RE: [PATCH] D16614: Use "long long int" when checking whether
> > atomics are supported.
> > 
> > > Why is this relevant for LLVM? I would call using 64bit atomics on 32bit
> > > architectures a bug waiting to happen.
> > >
> > > Joerg
> > 
> > Doesn't libatomic provide software implementation of atomic ops whose size
> > isn't supported natively by using barriers, locks, etc.?

Yes, but emulations larging the native register width tend to be
significantly slower and raise questions about signal safety and the
like. That makes them quite important to avoid for a lot of "production"
code.

> Just to add to this, it came up during the LLVM 3.8 testing since quite
> a few libcxx tests depend on 64-bit atomics. The compiler is using a
> builtin for <=32-bit atomics and an external library for the >=64-bit
> ones the architecture doesn't support directly.

I'm not surprised and I understand why libcxx tests want to avoid
additional problems. It all boils down to "on many 32bit architectures,
there are no true 64bit+ atomic ops".

Joerg