Skip to content

[android] Use emulated thread-local storage for API 28 and earlier #77883

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 9, 2025
+27 −0
Merged

[android] Use emulated thread-local storage for API 28 and earlier #77883

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions lib/IRGen/IRGen.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,6 +143,11 @@ swift::getIRTargetOptions(const IRGenOptions &Opts, ASTContext &Ctx) {
// Set UseInitArray appropriately.
TargetOpts.UseInitArray = Clang->getCodeGenOpts().UseInitArray;

// Set emulated TLS in inlined C/C++ functions based on what clang is doing,
// ie either setting the default based on the OS or -Xcc -f{no-,}emulated-tls
// command-line flags.
TargetOpts.EmulatedTLS = Clang->getCodeGenOpts().EmulatedTLS;

// WebAssembly doesn't support atomics yet, see
// https://github.com/apple/swift/issues/54533 for more details.
if (Clang->getTargetInfo().getTriple().isOSBinFormatWasm())
Expand Down
7 changes: 7 additions & 0 deletions test/IRGen/Inputs/tls.h
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
#include "shims/SwiftStdint.h"

static inline __swift_uint32_t _swift_stdlib_gettid() {
static __thread __swift_uint32_t tid = 0;

return tid;
}
15 changes: 15 additions & 0 deletions test/IRGen/emulated-tls.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
// RUN: %target-swift-frontend -Xcc -femulated-tls %s -S -import-objc-header %S/Inputs/tls.h | %FileCheck %s --check-prefix=EMUTLS --check-prefix=EMUTLS-%target-os
// RUN: %target-swift-frontend -Xcc -fno-emulated-tls %s -S -import-objc-header %S/Inputs/tls.h | %FileCheck %s --check-prefix=NOEMUTLS

_swift_stdlib_gettid()

// EMUTLS: __emutls_v._swift_stdlib_gettid.tid
// EMUTLS-linux-android: __emutls_get_address
// EMUTLS-linux-gnu: __emutls_get_address
// EMUTLS-macosx: __emutls_get_address
// EMUTLS-openbsd: __emutls_get_address
// EMUTLS-windows-msvc: __emutls_get_address
// EMUTLS-wasi-NOT: __emutls_get_address
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, why is this negated for WASI? Perhaps we should warn about the ignored setting?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly didn't want to deal with WASI at all, but was forced to because the linux CI builds it and runs these tests for it too.

My understanding is that the initial __emutls_v._swift_stdlib_gettid.tid symbol is swapped in because the LLVM codegen pass runs on all platforms, but it doesn't have __emutls_get_address in compiler-rt, like the other platforms do, so it doesn't call that function. I could've simply disabled this test for WASI instead, but I figured it was worth checking the __emutls_v._swift_stdlib_gettid.tid symbol at least on all platforms.

This is just an artifact of the current CI and WASI support, I don't think it's worth addressing in the test.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, okay, its just that the call is something else? That seems reasonable enough then. Perhaps an issue to track restoring this would be good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, okay, its just that the call is something else?

I don't know: I just did what I had to do to get the test to pass, as the CI was forcing me to address WASI but I'm not that familiar with it, didn't know if it even had threads yet. Looking at the relevant LLVM source now, the LowerToTLSEmulatedModel() method that inserts the __emutls_get_address call is not invoked for the WASM target, as it is for several other architectures. It appears that WASI threads is still in the standardization phase, so the implementation may still be in flux.

@kateinoigakukun, could you let us know if this might be a useful flag for WASM one day and if this test is okay for now?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All WebAssembly targets currently have proper TLS support (assuming dynamic linking is only for Emscripten, not with WASI), so the lowering does not implement emulation at all and silently ignores the option today as you mentioned. The thread representation model in Wasm is still unstable but I don't expect we need the emulation in the future, so it's fine as is now.


// NOEMUTLS-NOT: __emutls_v._swift_stdlib_gettid.tid
// NOEMUTLS-NOT: __emutls_get_address