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

[Vasileios Kalintiris via llvm-commits]

Daniel explained pretty much the reasoning behind this review request and its dependency. I'll wait a little bit and I'm going to commit it in order to fix the regressions in libcxx before the new release candidate. I believe that in most cases the information provided by is_lock_free() is good enough to avoid any problematic behaviour as far as signals are concerned.

- Vasileios
________________________________________
From: Daniel Sanders
Sent: 27 January 2016 15:23
To: Joerg Sonnenberger; Vasileios Kalintiris
Cc: llvm-commits at lists.llvm.org
Subject: RE: [PATCH] D16614: Use "long long int" when checking whether atomics are supported.

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