[all-commits] [llvm/llvm-project] 89fe08: [WebAssembly] Check features before making SjLj va...

[Thomas Lively via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 89fe083c197951a1380ee70e9e36e2aa95659da5
      https://github.com/llvm/llvm-project/commit/89fe083c197951a1380ee70e9e36e2aa95659da5
  Author: Thomas Lively <tlively at google.com>
  Date:   2020-09-25 (Fri, 25 Sep 2020)

  Changed paths:
    M llvm/include/llvm/Target/TargetMachine.h
    M llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
    M llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.h
    M llvm/test/CodeGen/WebAssembly/lower-em-exceptions.ll
    M llvm/test/CodeGen/WebAssembly/lower-em-sjlj.ll

  Log Message:
  -----------
  [WebAssembly] Check features before making SjLj vars thread-local

1c5a3c4d3823 updated the variables inserted by Emscripten SjLj lowering to be
thread-local, depending on the CoalesceFeaturesAndStripAtomics pass to downgrade
them to normal globals if the target features did not support TLS. However, this
had the unintended side effect of preventing all non-TLS-supporting objects from
being linked into modules with shared memory, because stripping TLS marks an
object as thread-unsafe. This patch fixes the problem by only making the SjLj
lowering variables thread-local if the target machine supports TLS so that it
never introduces new usage of TLS that will be stripped. Since SjLj lowering
works on Modules instead of Functions, this required that the
WebAssemblyTargetMachine have its feature string updated to reflect the
coalesced features collected from all the functions so that a
WebAssemblySubtarget can be created without using any particular function.

Differential Revision: https://reviews.llvm.org/D88323