| #
4facbf21 |
| 10-Jun-2021 |
Paulo Matos <[email protected]> |
[WebAssembly] Implementation of global.get/set for reftypes in LLVM IR
Reland of 31859f896.
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and lowering methods for load and stores of r
[WebAssembly] Implementation of global.get/set for reftypes in LLVM IR
Reland of 31859f896.
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and lowering methods for load and stores of reference types from IR globals. Once the lowering creates the new nodes, tablegen pattern matches those and converts them to Wasm global.get/set.
Differential Revision: https://reviews.llvm.org/D104797
show more ...
|
| #
64de8763 |
| 10-Jun-2021 |
David Spickett <[email protected]> |
Revert "Implementation of global.get/set for reftypes in LLVM IR"
This reverts commit 31859f896cf90d64904134ce7b31230f374c3fcc.
Causing SVE and RISCV-V test failures on bots.
|
| #
31859f89 |
| 10-Jun-2021 |
Paulo Matos <[email protected]> |
Implementation of global.get/set for reftypes in LLVM IR
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and lowering methods for load and stores of reference types from IR globals. Once
Implementation of global.get/set for reftypes in LLVM IR
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and lowering methods for load and stores of reference types from IR globals. Once the lowering creates the new nodes, tablegen pattern matches those and converts them to Wasm global.get/set.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D95425
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
a64ebb86 |
| 23-May-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Add NullifyDebugValueLists pass
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the const
[WebAssembly] Add NullifyDebugValueLists pass
`WebAssemblyDebugValueManager` does not currently handle `DBG_VALUE_LIST`, which is a recent addition to LLVM. We tried to nullify them within the constructor of `WebAssemblyDebugValueManager` in D102589, but it made the class error-prone to use because it deletes instructions within the constructor and thus invalidates existing iterators within the BB, so the user of the class should take special care not to use invalidated iterators. This actually caused a bug in ExplicitLocals pass.
Instead of trying to fix ExplicitLocals pass to make the iterator usage correct, which is possible but error-prone, this adds NullifyDebugValueLists pass that nullifies all `DBG_VALUE_LIST` instructions before we run WebAssembly specific passes in the backend. We can remove this pass after we implement handlers for `DBG_VALUE_LIST`s in `WebAssemblyDebugValueManager` and elsewhere.
Fixes https://github.com/emscripten-core/emscripten/issues/14255.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D102999
show more ...
|
| #
d7086af2 |
| 04-May-2021 |
Paulo Matos <[email protected]> |
[WebAssembly] Support for WebAssembly globals in LLVM IR
This patch adds support for WebAssembly globals in LLVM IR, representing them as pointers to global values, in a non-default, non-integral ad
[WebAssembly] Support for WebAssembly globals in LLVM IR
This patch adds support for WebAssembly globals in LLVM IR, representing them as pointers to global values, in a non-default, non-integral address space. Instruction selection legalizes loads and stores to these pointers to new WebAssemblyISD nodes GLOBAL_GET and GLOBAL_SET. Once the lowering creates the new nodes, tablegen pattern matches those and converts them to Wasm global.get/set of the appropriate type.
Based on work by Paulo Matos in https://reviews.llvm.org/D95425.
Reviewed By: pmatos
Differential Revision: https://reviews.llvm.org/D101608
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
561abd83 |
| 02-Mar-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Disable uses of __clang_call_terminate
Background:
Wasm EH, while using Windows EH (catchpad/cleanuppad based) IR, uses Itanium-based libraries and ABIs with some modifications.
`__c
[WebAssembly] Disable uses of __clang_call_terminate
Background:
Wasm EH, while using Windows EH (catchpad/cleanuppad based) IR, uses Itanium-based libraries and ABIs with some modifications.
`__clang_call_terminate` is a wrapper generated in Clang's Itanium C++ ABI implementation. It contains this code, in C-style pseudocode: ``` void __clang_call_terminate(void *exn) { __cxa_begin_catch(exn); std::terminate(); } ``` So this function is a wrapper to call `__cxa_begin_catch` on the exception pointer before termination.
In Itanium ABI, this function is called when another exception is thrown while processing an exception. The pointer for this second, violating exception is passed as the argument of this `__clang_call_terminate`, which calls `__cxa_begin_catch` with that pointer and calls `std::terminate` to terminate the program.
The spec (https://libcxxabi.llvm.org/spec.html) for `__cxa_begin_catch` says, ``` When the personality routine encounters a termination condition, it will call __cxa_begin_catch() to mark the exception as handled and then call terminate(), which shall not return to its caller. ```
In wasm EH's Clang implementation, this function is called from cleanuppads that terminates the program, which we also call terminate pads. Cleanuppads normally don't access the thrown exception and the wasm backend converts them to `catch_all` blocks. But because we need the exception pointer in this cleanuppad, we generate `wasm.get.exception` intrinsic (which will eventually be lowered to `catch` instruction) as we do in the catchpads. But because terminate pads are cleanup pads and should run even when a foreign exception is thrown, so what we have been doing is: 1. In `WebAssemblyLateEHPrepare::ensureSingleBBTermPads()`, we make sure terminate pads are in this simple shape: ``` %exn = catch call @__clang_call_terminate(%exn) unreachable ``` 2. In `WebAssemblyHandleEHTerminatePads` pass at the end of the pipeline, we attach a `catch_all` to terminate pads, so they will be in this form: ``` %exn = catch call @__clang_call_terminate(%exn) unreachable catch_all call @std::terminate() unreachable ``` In `catch_all` part, we don't have the exception pointer, so we call `std::terminate()` directly. The reason we ran HandleEHTerminatePads at the end of the pipeline, separate from LateEHPrepare, was it was convenient to assume there was only a single `catch` part per `try` during CFGSort and CFGStackify.
---
Problem:
While it thinks terminate pads could have been possibly split or calls to `__clang_call_terminate` could have been duplicated, `WebAssemblyLateEHPrepare::ensureSingleBBTermPads()` assumes terminate pads contain no more than calls to `__clang_call_terminate` and `unreachable` instruction. I assumed that because in LLVM very limited forms of transformations are done to catchpads and cleanuppads to maintain the scoping structure. But it turned out to be incorrect; passes can merge cleanuppads into one, including terminate pads, as long as the new code has a correct scoping structure. One pass that does this I observed was `SimplifyCFG`, but there can be more. After this transformation, a single cleanuppad can contain any number of other instructions with the call to `__clang_call_terminate` and can span many BBs. It wouldn't be practical to duplicate all these BBs within the cleanuppad to generate the equivalent `catch_all` blocks, only with calls to `__clang_call_terminate` replaced by calls to `std::terminate`.
Unless we do more complicated transformation to split those calls to `__clang_call_terminate` into a separate cleanuppad, it is tricky to solve.
---
Solution (?):
This CL just disables the generation and use of `__clang_call_terminate` and calls `std::terminate()` directly in its place.
The possible downside of this approach can be, because the Itanium ABI intended to "mark" the violating exception handled, we don't do that anymore. What `__cxa_begin_catch` actually does is increment the exception's handler count and decrement the uncaught exception count, which in my opinion do not matter much given that we are about to terminate the program anyway. Also it does not affect info like stack traces that can be possibly shown to developers.
And while we use a variant of Itanium EH ABI, we can make some deviations if we choose to; we are already different in that in the current version of the EH spec we don't support two-phase unwinding. We can possibly consider a more complicated transformation later to reenable this, but I don't think that has high priority.
Changes in this CL contains: - In Clang, we don't generate a call to `wasm.get.exception()` intrinsic and `__clang_call_terminate` function in terminate pads anymore; we simply generate calls to `std::terminate()`, which is the default implementation of `CGCXXABI::emitTerminateForUnexpectedException`. - Remove `WebAssembly::ensureSingleBBTermPads() function and `WebAssemblyHandleEHTerminatePads` pass, because terminate pads are already `catch_all` now (because they don't need the exception pointer) and we don't need these transformations anymore. - Change tests to use `std::terminate` directly. Also removes tests that tested `LateEHPrepare::ensureSingleBBTermPads` and `HandleEHTerminatePads` pass. - Drive-by fix: Add some function attributes to EH intrinsic declarations
Fixes https://github.com/emscripten-core/emscripten/issues/13582.
Reviewed By: dschuff, tlively
Differential Revision: https://reviews.llvm.org/D97834
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
be0efa1f |
| 01-Jan-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Handle EH terminate pads for cleanup
Terminate pads, cleanup pads with `__clang_call_terminate` call, have `catch` instruction in them because `__clang_call_terminate` takes an excepti
[WebAssembly] Handle EH terminate pads for cleanup
Terminate pads, cleanup pads with `__clang_call_terminate` call, have `catch` instruction in them because `__clang_call_terminate` takes an exception pointer. But these terminate pads should be reached also in case of foreign exception. So this pass attaches an additional `catch_all` BB after every terminate pad BB, with a call to `std::terminate`.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D94050
show more ...
|
| #
9e4eadeb |
| 26-Dec-2020 |
Heejin Ahn <[email protected]> |
[WebAssembly] Update basic EH instructions for the new spec
This implements basic instructions for the new spec.
- Adds new versions of instructions: `catch`, `catch_all`, and `rethrow` - Adds supp
[WebAssembly] Update basic EH instructions for the new spec
This implements basic instructions for the new spec.
- Adds new versions of instructions: `catch`, `catch_all`, and `rethrow` - Adds support for instruction selection for the new instructions - `catch` needs a custom routine for the same reason `throw` needs one, to encode `__cpp_exception` tag symbol. - Updates `WebAssembly::isCatch` utility function to include `catch_all` and Change code that compares an instruction's opcode with `catch` to use that function. - LateEHPrepare - Previously in LateEHPrepare we added `catch` instruction to both `catchpad`s (for user catches) and `cleanuppad`s (for destructors). In the new version `catch` is generated from `llvm.catch` intrinsic in instruction selection phase, so we only need to add `catch_all` to the beginning of cleanup pads. - `catch` is generated from instruction selection, but we need to hoist the `catch` instruction to the beginning of every EH pad, because `catch` can be in the middle of the EH pad or even in a split BB from it after various code transformations. - Removes `addExceptionExtraction` function, which was used to generate `br_on_exn` before. - CFGStackfiy: Deletes `fixUnwindMismatches` function. Running this function on the new instruction causes crashes, and the new version will be added in a later CL, whose contents will be completely different. So deleting the whole function will make the diff easier to read. - Reenables all disabled tests in exception.ll and eh-lsda.ll and a single basic test in cfg-stackify-eh.ll. - Updates existing tests to use the new assembly format. And deletes `br_on_exn` instructions from the tests and FileCheck lines.
Reviewed By: dschuff, tlively
Differential Revision: https://reviews.llvm.org/D94040
show more ...
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3 |
|
| #
c9122dde |
| 22-Feb-2019 |
Matt Arsenault <[email protected]> |
CodeGen: Refactor regallocator command line and target selection
Make the sequence of passes to select and rewrite instructions to physical registers be a target callback. This is to prepare to allo
CodeGen: Refactor regallocator command line and target selection
Make the sequence of passes to select and rewrite instructions to physical registers be a target callback. This is to prepare to allow targets to split register allocation into multiple phases.
show more ...
|
| #
a28a4662 |
| 11-Nov-2020 |
Sam Clegg <[email protected]> |
[WebAssembly] Add new relocation type for TLS data symbols
These relocations represent offsets from the __tls_base symbol.
Previously we were just using normal MEMORY_ADDR relocations and relying o
[WebAssembly] Add new relocation type for TLS data symbols
These relocations represent offsets from the __tls_base symbol.
Previously we were just using normal MEMORY_ADDR relocations and relying on the linker to select a segment-offset rather and absolute value in Symbol::getVirtualAddress(). Using an explicit relocation type allows allow us to clearly distinguish absolute from relative relocations based on the relocation information alone.
One place this is useful is being able to reject absolute relocation in the PIC case, but still accept TLS relocations.
Differential Revision: https://reviews.llvm.org/D91276
show more ...
|
| #
3bba91f6 |
| 28-Sep-2020 |
Heejin Ahn <[email protected]> |
[WebAssembly] Rename Emscripten EH functions
Renaming for some Emscripten EH functions has so far been done in wasm-emscripten-finalize tool in Binaryen. But recently we decided to make a compilatio
[WebAssembly] Rename Emscripten EH functions
Renaming for some Emscripten EH functions has so far been done in wasm-emscripten-finalize tool in Binaryen. But recently we decided to make a compilation/linking path that does not rely on wasm-emscripten-finalize for modifications, so here we move that functionality to LLVM.
Invoke wrappers are generated in LowerEmscriptenEHSjLj pass, but final wasm types are not available in the IR pass, we need to rename them at the end of the pipeline.
This patch also removes uses of `emscripten_longjmp_jmpbuf` in LowerEmscriptenEHSjLj pass, replacing that with `emscripten_longjmp`. `emscripten_longjmp_jmpbuf` is lowered to `emscripten_longjmp`, but previously we generated calls to `emscripten_longjmp_jmpbuf` in LowerEmscriptenEHSjLj pass because it takes `jmp_buf*` instead of `i32`. But we were able use `ptrtoint` to make it use `emscripten_longjmp` directly here.
Addresses: https://github.com/WebAssembly/binaryen/issues/3043 https://github.com/WebAssembly/binaryen/issues/3081
Companions: https://github.com/WebAssembly/binaryen/pull/3191 https://github.com/emscripten-core/emscripten/pull/12399
Reviewed By: dschuff, tlively, sbc100
Differential Revision: https://reviews.llvm.org/D88697
show more ...
|
| #
89fe083c |
| 25-Sep-2020 |
Thomas Lively <[email protected]> |
[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 CoalesceFeaturesAndStri
[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
show more ...
|
| #
1c5a3c4d |
| 24-Sep-2020 |
Thomas Lively <[email protected]> |
[WebAssembly] Make SjLj lowering globals thread-local
Emscripten's longjump and exception mechanism depends on two global variables, `__THREW__` and `__threwValue`, which are changed to be defined a
[WebAssembly] Make SjLj lowering globals thread-local
Emscripten's longjump and exception mechanism depends on two global variables, `__THREW__` and `__threwValue`, which are changed to be defined as thread-local in https://github.com/emscripten-core/emscripten/pull/12056. This patch updates the corresponding code in the WebAssembly backend to properly declare these globals as thread-local as well.
Differential Revision: https://reviews.llvm.org/D88262
show more ...
|
| #
aab90384 |
| 28-Aug-2020 |
Craig Topper <[email protected]> |
[Attributes] Add a method to check if an Attribute has AttrKind None. Use instead of hasAttribute(Attribute::None)
There's a special case in hasAttribute for None when pImpl is null. If pImpl is not
[Attributes] Add a method to check if an Attribute has AttrKind None. Use instead of hasAttribute(Attribute::None)
There's a special case in hasAttribute for None when pImpl is null. If pImpl is not null we dispatch to pImpl->hasAttribute which will always return false for Attribute::None.
So if we just want to check for None its sufficient to just check that pImpl is null. Which can even be done inline.
This patch adds a helper for that case which I hope will speed up our getSubtargetImpl implementations.
Differential Revision: https://reviews.llvm.org/D86744
show more ...
|
| #
7f50c15b |
| 03-Jun-2020 |
Thomas Lively <[email protected]> |
Reland "[WebAssembly] Eliminate range checks on br_tables"
This reverts commit 755a89591528b692315ad0325347e2fd4637271b. Although I was not able to reproduce any test failures locally, aheejin was a
Reland "[WebAssembly] Eliminate range checks on br_tables"
This reverts commit 755a89591528b692315ad0325347e2fd4637271b. Although I was not able to reproduce any test failures locally, aheejin was able to reproduce them and found a fix, applied here.
show more ...
|
| #
755a8959 |
| 03-Jun-2020 |
Thomas Lively <[email protected]> |
Revert "[WebAssembly] Eliminate range checks on br_tables"
This reverts commit f99d5f8c32a822580a732d15a34e8197da55d22b. The change was causing UBSan and other failures on some bots.
|
| #
f99d5f8c |
| 02-Jun-2020 |
Thomas Lively <[email protected]> |
[WebAssembly] Eliminate range checks on br_tables
Summary: Jump tables for most targets cannot handle out of range indices by themselves, so LLVM emits range checks to guard the jump tables. WebAsse
[WebAssembly] Eliminate range checks on br_tables
Summary: Jump tables for most targets cannot handle out of range indices by themselves, so LLVM emits range checks to guard the jump tables. WebAssembly, on the other hand, implements jump tables using the br_table instruction, which takes a default branch target as an operand, making the range checks redundant. This patch introduces a new MachineFunction pass in the WebAssembly backend to find and eliminate the redundant range checks.
Reviewers: aheejin, dschuff
Subscribers: mgorny, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80863
show more ...
|
| #
2b7fe086 |
| 30-Apr-2020 |
Wouter van Oortmerssen <[email protected]> |
[WebAssembly] Added Debug Fixup pass
This pass changes debug_value instructions referring to stackified registers into TI_OPERAND_STACK with correct stack depth.
|
| #
a1ae9566 |
| 07-May-2020 |
Thomas Lively <[email protected]> |
[WebAssembly] Disallow 'shared-mem' rather than 'atomics'
Summary: The WebAssembly backend automatically lowers atomic operations and TLS to nonatomic operations and non-TLS data when either are pre
[WebAssembly] Disallow 'shared-mem' rather than 'atomics'
Summary: The WebAssembly backend automatically lowers atomic operations and TLS to nonatomic operations and non-TLS data when either are present and the atomics or bulk-memory features are not present, respectively. The resulting object is no longer thread-safe, so the linker has to be told not to allow it to be linked into a module with shared memory. This was previously done by disallowing the 'atomics' feature, which prevented any objct with its atomic operations or TLS removed from being linked with any object containing atomics or TLS, and therefore preventing it from being linked into a module with shared memory since shared memory requires atomics.
However, as of https://github.com/WebAssembly/threads/issues/144, the validation rules are relaxed to allow atomic operations to validate with unshared memories, which makes it perfectly safe to link an object with stripped atomics and TLS with another object that still contains TLS and atomics as long as the resulting module has an unshared memory. To allow this kind of link, this patch disallows a pseudo-feature 'shared-mem' rather than 'atomics' to communicate to the linker that the object is not thread-safe. This means that the 'atomics' feature is available to accurately reflect whether or not an object has atomics enabled.
As a drive-by tweak, this change also requires that bulk-memory be enabled in addition to atomics in order to use shared memory. This is because initializing shared memories requires bulk-memory operations.
Reviewers: aheejin, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79542
show more ...
|
| #
ca9ba764 |
| 07-Feb-2020 |
Thomas Lively <[email protected]> |
[WebAssembly] Replace all calls with generalized multivalue calls
Summary: Extends the multivalue call infrastructure to tail calls, removes all legacy calls specialized for particular result types,
[WebAssembly] Replace all calls with generalized multivalue calls
Summary: Extends the multivalue call infrastructure to tail calls, removes all legacy calls specialized for particular result types, and removes the CallIndirectFixup pass, since all indirect call arguments are now fixed up directly in the post-insertion hook.
In order to keep supporting pretty-printed defs and uses in test expectations, MCInstLower now inserts an immediate containing the number of defs for each call and call_indirect. The InstPrinter is updated to query this immediate if it is present and determine which MCOperands are defs and uses accordingly.
Depends on D72902.
Reviewers: aheejin
Subscribers: dschuff, mgorny, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74192
show more ...
|
| #
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <[email protected]> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
| #
0dbcb363 |
| 15-Jan-2020 |
Tom Stellard <[email protected]> |
CMake: Make most target symbols hidden by default
Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by
CMake: Make most target symbols hidden by default
Summary: For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF this change makes all symbols in the target specific libraries hidden by default.
A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these libraries public, which is mainly needed for the definitions of the LLVMInitialize* functions.
This patch reduces the number of public symbols in libLLVM.so by about 25%. This should improve load times for the dynamic library and also make abi checker tools, like abidiff require less memory when analyzing libLLVM.so
One side-effect of this change is that for builds with LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that access symbols that are no longer public will need to be statically linked.
Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1): nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 36221 nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l 26278
Reviewers: chandlerc, beanz, mgorny, rnk, hans
Reviewed By: rnk, hans
Subscribers: merge_guards_bot, luismarques, smeenai, ldionne, lenary, s.egerton, pzheng, sameer.abuasal, MaskRay, wuzish, echristo, Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D54439
show more ...
|
| #
0eaee545 |
| 15-Aug-2019 |
Jonas Devlieghere <[email protected]> |
[llvm] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of
[llvm] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo.
llvm-svn: 369013
show more ...
|
| #
42bba4b8 |
| 16-Jul-2019 |
Guanzhong Chen <[email protected]> |
[WebAssembly] Implement thread-local storage (local-exec model)
Summary: Thread local variables are placed inside a `.tdata` segment. Their symbols are offsets from the start of the segment. The add
[WebAssembly] Implement thread-local storage (local-exec model)
Summary: Thread local variables are placed inside a `.tdata` segment. Their symbols are offsets from the start of the segment. The address of a thread local variable is computed as `__tls_base` + the offset from the start of the segment.
`.tdata` segment is a passive segment and `memory.init` is used once per thread to initialize the thread local storage.
`__tls_base` is a wasm global. Since each thread has its own wasm instance, it is effectively thread local. Currently, `__tls_base` must be initialized at thread startup, and so cannot be used with dynamic libraries.
`__tls_base` is to be initialized with a new linker-synthesized function, `__wasm_init_tls`, which takes as an argument a block of memory to use as the storage for thread locals. It then initializes the block of memory and sets `__tls_base`. As `__wasm_init_tls` will handle the memory initialization, the memory does not have to be zeroed.
To help allocating memory for thread-local storage, a new compiler intrinsic is introduced: `__builtin_wasm_tls_size()`. This instrinsic function returns the size of the thread-local storage for the current function.
The expected usage is to run something like the following upon thread startup:
__wasm_init_tls(malloc(__builtin_wasm_tls_size()));
Reviewers: tlively, aheejin, kripken, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64537
llvm-svn: 366272
show more ...
|
| #
ec4be576 |
| 03-Jul-2019 |
Derek Schuff <[email protected]> |
[WebAssembly] Enable IndirectBrExpandPass
Wasm doesn't have a direct way to lower indirectbr, so hook up the IndirectBrExpandPass to lower indirectbr into a switch.
Fixes PR42498
Reviewers: aheeji
[WebAssembly] Enable IndirectBrExpandPass
Wasm doesn't have a direct way to lower indirectbr, so hook up the IndirectBrExpandPass to lower indirectbr into a switch.
Fixes PR42498
Reviewers: aheejin
Differential Revision: https://reviews.llvm.org/D64161
llvm-svn: 365096
show more ...
|