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

[Daniel Sanders via llvm-commits]

Hi,

It was probably the Reply-To bug that removed me, but please keep me on the recipients list. If I'm not directly address on an email then it ends up in a folder instead of my inbox.

> -----Original Message-----
> From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf
> Of Joerg Sonnenberger via llvm-commits
> Sent: 27 January 2016 13:55
> To: llvm-commits at lists.llvm.org
> Subject: Re: [PATCH] D16614: Use "long long int" when checking whether
> atomics are supported.
> 
> 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.

It's true that users may want to avoid them for performance reasons but this doesn't mean we should fail to compile code that contains emulated atomics.

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

That's right, but not having a native implementation for an operation shouldn't prevent valid C++ from building. If we have to emulate operations to support the language on our architecture then that's what we must do.

> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits