[builtins] Only include LSE if available

[bnbarham]

These fail to build with MSVC, resulting in eventual link failures as the outline_atomic_*.S.obj are all missing.

[bnbarham]

@swift-ci please test

[bnbarham]

Hmmm, this is not correct. On both stable/20230725 and stable/20240723 I see the following for aarch64:

-- Performing Test COMPILER_RT_HAS_ASM_LSE
-- Performing Test COMPILER_RT_HAS_ASM_LSE - Success

And on stable/20230725 these are all built, eg.:

[134/280][ 47%][4.521s]Building ASM object CMakeFiles\clang_rt.builtins-aarch64.dir\outline_atomic_helpers.dir\outline_atomic_cas1_3.S.obj
[135/280][ 48%][4.531s]Building ASM object CMakeFiles\clang_rt.builtins-aarch64.dir\outline_atomic_helpers.dir\outline_atomic_cas1_4.S.obj

But on stable/20240723:

[257/401][ 64%][2.891s]Building ASM object CMakeFiles\clang_rt.builtins-aarch64.dir\outline_atomic_helpers.dir\outline_atomic_cas1_4.S.obj
Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33523 for ARM64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release

cl : Command line warning D9024 : unrecognized source file type 'T:\5\runtimes\builtins-aarch64-unknown-windows-msvc-bins\outline_atomic_helpers.dir\outline_atomic_cas1_4.S', object file assumed

cl : Command line warning D9027 : source file 'T:\5\runtimes\builtins-aarch64-unknown-windows-msvc-bins\outline_atomic_helpers.dir\outline_atomic_cas1_4.S' ignored

cl : Command line warning D9021 : no action performed

So it seems the compilation command itself has changed 🤔

[bnbarham]

We seem to flip-flop on the compiler being used, but the last before the error is hit in both is:

-- The ASM compiler identification is MSVC
-- Found assembler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.39.33519/bin/Hostx64/arm64/cl.exe

[compnerd]

The contents of the file must have changed or the CMake detection of them. They should not be treated as assembly but rather CPP+Assembly. That means that they need to be pre-processed before being passed to the assembler. However, MASM has a different syntax than GNU.

[bnbarham]

The contents of the file must have changed

The only change was 4bb2416 and that just added another "model" (5). But they're all failing, not just 5.

or the CMake detection of them

Maybe, but I'm not sure how. We should be using the same MSVC + cmake in both.

---

The only semi-relevant change I can find is 4dec62f but all it's doing is adding a custom command rather than using BYPRODUCTS. But it's still the same otherwise, ie. copies lse.S a bunch of times into different files with different defines set for each.

A verbose log might help here, but there's no PR testing for arm64 windows yet :(

[bnbarham]

However, MASM has a different syntax than GNU.

I'm very confused as to how this is "working" on stable/20230725. CompilerRT only has:

  project(CompilerRT C CXX ASM)

not ASM_MASM.

And:

However, MASM has a different syntax than GNU.

Would mean that they couldn't possibly be being compiled.

If I ignore stable/20230725 saying they're building, what's the correct check here in your opinion? Just MSVC? NOT CMAKE_ASM_COMPILER_ID MATCHES MSVC? Something else?

[bnbarham]

@swift-ci please test