Require the cx16 feature on Intel CPUs when threading is enabled

[eschnett]

This makes 128-bit atomics work on Intel. Without this feature, LLVM does not always know how to generate the respective code.

The CPU feature cx16 describes whether the CPU supports the cmpxchg16b instruction. All modern Intel CPUs support this feature; see the discussion in #14818.

When Julia generates code for a native 64-bit CPU, this flag is already set correctly. However, when Julia generates code for either a 32-bit or a generic Intel CPU, then LLVM assumes pessimistically that this feature is not present. According to Wikipedia https://en.wikipedia.org/wiki/X86-64, this is only relevant for "early AMD64 processors", and "the 64-bit version of Windows 8.1 requires the instruction". I thus suggest to require this instruction as well when threading is enabled.

The alternative is to disable support for 128-bit atomics. The generic CPU target is apparently specified at many occasions, including for 32-bit Intel CPUs and in Travis.

Closes #14818.

[tkelman]

What is the earliest 32 bit x86 processor family that implements this?

[eschnett]

@tkelman I found this: http://www.tomshardware.com/answers/id-2396559/cmpxchg16b-compatible-cpu.html (this forum usually has reliable information):

"Intel introduced the CMPXCHG16B (aka cx16) instruction first with the P4 Prescott/Pentium D and then added it to the P6 derivative CPUs with the Core 2 Duo. [...]

"AMD added the instruction to Bulldozer, Jaguar, and later CPU cores."

[tkelman]

I think we may as well try this and see whether it causes any issues on old hardware.

[eschnett]

@tkelman Can I interpret this as "LGTM"? (I'd like to repeat this only affects builds with threading enabled.)

[tkelman]

The fact that we don't always build with threading enabled means it would probably take longer to notice any ill effects of this.

[eschnett]

True. So do you lean towards "try to break it early and visibly", "try it timidly in a corner", or "leave out support for In128"?

In the latter case, we can still detect at run time how Julia has been configured, and enable Int128 atomics if they work, but this would then see no Travis coverage.

[tkelman]

While master is still in an unstable dev period I lean towards the former, let's find out if there are users on nightlies where this might break things (if we can work out our nightly frequency issues). Hardware dependent conditions just need lots of users to try things out and report back.

[nalimilan]

I agree, if we want to rely on this from now on, better make it visible so that we get feedback.

[tkelman]

this function should be re indented to 4 spaces, but that wasn't your doing

[tkelman]

This feature requirement should probably also be conditional on LLVM version. We're still kind of supporting building against old LLVM until we've fixed the compiler performance regressions, and on 3.3 this gives a warning on startup that '+cx16' is not a recognized feature for this target.

[vtjnash]

i have that fixed locally and plan to make a PR soon.