This is an archive of the discontinued LLVM Phabricator instance.

Repair cmake libatomic check.
ClosedPublic

Authored by jyknight on Jun 15 2015, 11:44 AM.

Details

Summary

The cmake check for whether libatomic could be used had been
unconditionally setting the result to false. Which was somewhat
fortunate, because the prerequisite check for whether it was *needed*
was always claiming it was, even if it was not.

However, this made platforms where libatomic is actually necessary
fail to link.

Diff Detail

Event Timeline

jyknight updated this revision to Diff 27696.Jun 15 2015, 11:44 AM
jyknight retitled this revision from to Repair cmake libatomic check..
jyknight updated this object.
jyknight edited the test plan for this revision. (Show Details)
jyknight added a subscriber: Unknown Object (MLST).

BTW, I've tested this patch both on a platform that does need libatomic (sparc, with clang as host compiler), and two that don't (x86-64 and sparc with gcc host compiler) and verified that it does the right thing on both kinds.

chandlerc accepted this revision.Jun 15 2015, 5:54 PM
chandlerc added a reviewer: chandlerc.
chandlerc added a subscriber: chandlerc.

Looks good, but be cautious in landing this. There may be platforms where this detection scheme fails but where LLVM was by some miracle getting a working <atomic> header and we'll need to figure out why/how in order to get the detection to work.

Also, as a side note, file a bug to track LLVM being able to work on SPARC without libatomic? ;] If GCC can do it....

This revision is now accepted and ready to land.Jun 15 2015, 5:54 PM

Thanks. I'll land it in the morning when I can watch for problems. :)

As to the side note:

GCC can do it only because its default target on Debian is the "v8plus"
mode, which is the SparcV8 32bit calling convention/ABI, but assuming a
minimum of a Sparc V9 CPU to execute on. This allows the use of the V9
instructions, and the ability to store 64bit values in some of the
registers.

But, a base Sparc V8 truly cannot support native atomic-ops (in GCC
either), because it doesn't have a CAS instruction or LL/SC. The only
primitive atomic ops available are swap, load, and store, which are only
enough to implement locks.

There's not even any magic kernel userspace-helper routine for doing atomic
cmpxchg, like there is for ARMv5, presumably because nobody really cares
about base sparc v8: the v9 cpu was introduced 20 years ago, and even the
popular LEON embedded sparcv8 chip has CAS an an extension (though,
unfortunately incompatible with the v9 one, for somewhat-reasonable
reasons).

Anyways, currently LLVM supports v9 only in the 64bit ABI, not as a cpu for
the v8 ABI. Thus, the lack of atomics support here is actually working as
intended -- for the "v8" cpu that LLVM is compiling for.

This revision was automatically updated to reflect the committed changes.