[llvm] [llvm] Set emulated-tls by default for x86_64-windows-gnu target (PR #79542)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> msys2 is doing this patch too. We should just enable this upstream. https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-clang/0004-enable-emutls-for-mingw.patch

Not quite. Msys2 are enabling this patch conditionally, in some of their environments (the GCC based ones), but not in all of them - in particular, not in the clang based ones: https://github.com/msys2/MINGW-packages/blob/097b2e3ac9fbdda192010f2b111b6cc628cd1190/mingw-w64-clang/PKGBUILD#L165-L169

While this patch indeed does help interoperability with GCC based environments, in particular interop with libstdc++, this is an ABI break for all environments that currently use the Clang default of native TLS. I.e. this would be an ABI break for llvm-mingw, and for the clang environments in msys2, at the very least. Thus - in order to proceed with such a change, all the aspects of such an ABI break must be considered and agreed upon by involved vendors, CC @mati865 @lazka @jeremyd2019.

The title of this PR is misleading; it claims to enable this behaviour for the `x86_64-windows-gnu` target - while the patch actually enables it for all architectures.

For the x86 based targets, there could be some merit in doing a change like this, for interop with GCC. But for ARM targets, there's no preexisting GCC based environments to be compatible with, so there's really no reason to break ABI there. (There exists an ongoing effort to get a working aarch64-mingw target in GCC though, but it's not upstream yet, and AFAIK they are  at a stage where there might be various pieces missing wrt ABI compat from their side anyway.)

As for the implications of a potential ABI break: With native TLS, which is the default in llvm-mingw and the msys2 clang environments, one cannot do direct access to TLS variables across DLL boundaries (i.e., any access to a TLS variable from another DLL needs to happen via an accessor function). (Overall this is a reasonable design anyway - keeping the individual TLS variables as `static` within one translation unit greatly simplifies the code generation for accessing it, and it avoids or used to avoid GCC issues with that anyway, see e.g. 7106f588567b59acb17c77f6116ba433b6226333.)

If there's no access to TLS variables across DLLs, the scope of an ABI break mostly is within individual DLLs, i.e. it would affect existing object files, and static libraries. Such an ABI break could maybe be tolerable, if other things work out. What do the msys2 maintainers think about that?

Finally, I have concerns about how this could interact with lower level constructs. Apparently one such issue has already been encountered and fixed by @jeremyd2019 in https://github.com/mingw-w64/mingw-w64/commit/6ded96c2a5c1666bb6fbd7e793e1cc61acdcc6d7. There could potentially be other such issues elsewhere - this would need to be test run a fair bit before I'd be comfortable changing it, from the llvm-mingw point of view. (Note to self: Related issues to look into, https://github.com/llvm/llvm-project/issues/78207 and https://reviews.llvm.org/D155278.)

In short: This needs to be reframed to acknowledge that it is an ABI break. If the relevant stakeholders agree, we could consider taking such an ABI break, but such a discussion needs to be had first. This should be changed to only affect i386 and x86_64, but no other architectures. And we would need to testrun this a bit to make sure it doesn't regress corner cases in existing setups in e.g. llvm-mingw.

https://github.com/llvm/llvm-project/pull/79542