[WebAssembly] Always inline atomics

[jgravelle-google]

Summary

Wasm MVP doesn't have any mechanism to respect atomicity. Skip emitting
libcalls for the time being.

[sunfish]

Since we may soon have people prototyping actual atomics, I'd prefer to find a less invasive way to fix this.

Would it be difficult to enable atomic.c in Emscripten's compiler-rt build, to define these libcalls (assuming that the problem is just that they're not currently defined)?

Alternatively, could we make the change in the patch guarded by if (CodeGenOpts.ThreadModel == "single") or so, so that it doesn't affect the "posix" case?

[dschuff]

Making it guarded by thread model makes sense, although I'm not exactly sure whether emscripten sets that or not. But even when we do start prototyping actual atomics, I had assumed we'd be defining i64 atomics symmetrically along with i32 atomics, in which case we wouldn't be emitting libcalls anyway.

test/Preprocessor/init.c

8613

I'm not sure we actually want to set this; it's possible that even if 64-bit atomics are specified by the wasm platform we may not promise that they have to be lock-free.

[sunfish]

(Emscripten does set the thread model.)

Whether WebAssembly should provide 64-bit atomics when on hardware where they're not lock-free is an interesting wasm design question, and the code here and in target-independent parts of clang may need to be changed as a result (right now, clang's target-independent code automatically defines __GCC_ATOMIC_LLONG_LOCK_FREE to 2 with this patch, which is incorrect).

So that's a separate topic. I'd like to keep changes meant to fix the -mthread-model single case.

[jgravelle-google]

In D28381#637915, @sunfish wrote:

Would it be difficult to enable atomic.c in Emscripten's compiler-rt build, to define these libcalls (assuming that the problem is just that they're not currently defined)?

Tried it and it seems to work. I needed to add -mthread-model single to the compiler_rt build flags to get it to build. Which makes me think we'll have issues when we actually support "posix".

Alternatively, could we make the change in the patch guarded by if (CodeGenOpts.ThreadModel == "single") or so, so that it doesn't affect the "posix" case?

We don't have access to GodeGenOpts in the constructor as far as I know, and the only TargetInfo method that does is adjustTargetOptions, which is const for the target.

My ideal patch here is to make the smallest change that doesn't need to be totally undone later, that also avoids making assumptions about how we'll implement wasm atomics down the line.
Talked with @dschuff, and we're probably going to go the compiler-rt route. Need to first explore whether it'd be saner to just drop in the real atomic.c or to stub one out for now.

[jgravelle-google]

Abandoning this in favor of https://github.com/kripken/emscripten/pull/4846

lib/Basic/Targets.cpp

 #include "clang/Basic/BuiltinsWebAssembly.def"
 };
 
 class WebAssembly32TargetInfo : public WebAssemblyTargetInfo {
 public:
   explicit WebAssembly32TargetInfo(const llvm::Triple &T,
                                    const TargetOptions &Opts)
       : WebAssemblyTargetInfo(T, Opts) {
-    MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 32;
+    // WebAssembly MVP has no way to express atomics, so always inline them
+    MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
     resetDataLayout("e-m:e-p:32:32-i64:64-n32:64-S128");
   }
 
 protected:
   void getTargetDefines(const LangOptions &Opts,
                         MacroBuilder &Builder) const override {
     WebAssemblyTargetInfo::getTargetDefines(Opts, Builder);
     defineCPUMacros(Builder, "wasm32", /*Tuning=*/false);

test/Preprocessor/init.c

 // WEBASSEMBLY32-NEXT:#define __FLT_MIN_EXP__ (-125)
 // WEBASSEMBLY32-NEXT:#define __FLT_MIN__ 1.17549435e-38F
 // WEBASSEMBLY32-NEXT:#define __FLT_RADIX__ 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_INT_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LONG_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
 // WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __GNUC_MINOR__ {{.*}}
 // WEBASSEMBLY32-NEXT:#define __GNUC_PATCHLEVEL__ {{.*}}
 // WEBASSEMBLY32-NEXT:#define __GNUC_STDC_INLINE__ 1