Currently wasm adds an extra level of options that work backwards from the standard options, and overwrites them. The ExceptionModel field in TM->Options is the standard user configuration option for the exception model to use. MCAsmInfo's ExceptionsType is a constant for the default to use for the triple if not explicitly set in the TargetOptions ExceptionModel. This was adding 2 custom flags, changing the MCAsmInfo default, and overwriting the ExceptionModel from the custom flags. These comments about compiling bitcode with clang are describing a toolchain bug or user error. TargetOptions is bad, and we should move to eliminating it. It is module state not captured in the IR. Ideally the exception model should either come implied from the triple, or a module flag and not depend on this side state. Currently it is the responsibility of the toolchain and/or user to ensure the same command line flags are used at each phase of the compilation. It is not the backend's responsibilty to try to second guess these options. -wasm-enable-eh and -wasm-enable-sjlj should also be removed in favor of the standard exception control. I'm a bit confused by how all of these fields are supposed to interact, but there are a few uses in the backend that are directly looking at these flags instead of the already parsed ExceptionModel which need to be cleaned up. Additionally, this was enforcing some rules about the combinations of flags at a random point in the IR pass pipeline configuration. This is a module property that should be handled at TargetMachine construction time at the latest. This required adding flags to a few mir and clang tests which never got this far to avoid hitting the errors.
## Purpose This patch is one in a series of code-mods that annotate LLVM’s public interface for export. This patch annotates the `llvm/Target` library. These annotations currently have no meaningful impact on the LLVM build; however, they are a prerequisite to support an LLVM Windows DLL (shared library) build. ## Background This effort is tracked in #109483. Additional context is provided in [this discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307), and documentation for `LLVM_ABI` and related annotations is found in the LLVM repo [here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst). A sub-set of these changes were generated automatically using the [Interface Definition Scanner (IDS)](https://github.com/compnerd/ids) tool, followed formatting with `git clang-format`. The bulk of this change is manual additions of `LLVM_ABI` to `LLVMInitializeX` functions defined in .cpp files under llvm/lib/Target. Adding `LLVM_ABI` to the function implementation is required here because they do not `#include "llvm/Support/TargetSelect.h"`, which contains the declarations for this functions and was already updated with `LLVM_ABI` in a previous patch. I considered patching these files with `#include "llvm/Support/TargetSelect.h"` instead, but since TargetSelect.h is a large file with a bunch of preprocessor x-macro stuff in it I was concerned it would unnecessarily impact compile times. In addition, a number of unit tests under llvm/unittests/Target required additional dependencies to make them build correctly against the LLVM DLL on Windows using MSVC. ## Validation Local builds and tests to validate cross-platform compatibility. This included llvm, clang, and lldb on the following configurations: - Windows with MSVC - Windows with Clang - Linux with GCC - Linux with Clang - Darwin with Clang
This replaces the existing `-wasm-enable-exnref` with `-wasm-use-legacy-eh` option, in an effort to make the new standardized exnref proposal the 'default' state and the legacy proposal needs to be separately enabled an option. But given that most users haven't switched to the new proposal and major web browsers haven't turned it on by default, this `-wasm-use-legacy-eh` is turned on by default, so nothing will change for now for the functionality perspective. This also removes the restriction that `-wasm-enable-exnref` be only used with `-wasm-enable-eh` because this option is enabled by default. This option does not have any effect when `-wasm-enable-eh` is not used.
The parameter is confusing as it duplicates MCStreamer::isVeboseAsm (initialized from MCTargetOptions::AsmVerbose). After 233cca169237b91d16092c82bd55ee6a283afe98, no in-tree target uses the parameter.
This adds `-wasm-enable-exnref`, which will enable the new EH instructions using `exnref` (adopted in Oct 2023 CG meeting): https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md This option should be used with `-wasm-enable-eh`.
For inline WebAssembly, passing a numeric operand to global.get is unsupported. This causes encodeInstruction to reach an llvm_unreachable call, leading to undefined behaviors. This patch fixes the issue for this invalid instruction encoding, making it report an error by adding an MCContext field in class WebAssemblyMCCodeEmitter. Reviewed By: sbc100, bryanpkc Differential Revision: https://reviews.llvm.org/D154734
WebAssemblyUtils depends on CodeGen which depends on all middle end optimization libraries. This component is used by WebAssembly's AsmParser, Disassembler, and MCTargetDesc libraries. Because of this, any MC layer tool built with WebAssembly support includes a larger portion of LLVM than it should. To fix this I've created an MC only version of WebAssemblyTypeUtilities.cpp in MCTargetDesc to be used by the MC components. This shrinks llvm-objdump and llvm-mc on my local release+asserts build by 5-6 MB. Reviewed By: MaskRay, aheejin Differential Revision: https://reviews.llvm.org/D144354
D25618 added a method to verify the instruction predicates for an emitted instruction, through verifyInstructionPredicates added into <Target>MCCodeEmitter::encodeInstruction. This is a very useful idea, but the implementation inside MCCodeEmitter made it only fire for object files, not assembly which most of the llvm test suite uses. This patch moves the code into the <Target>_MC::verifyInstructionPredicates method, inside the InstrInfo. The allows it to be called from other places, such as in this patch where it is called from the <Target>AsmPrinter::emitInstruction methods which should trigger for both assembly and object files. It can also be called from other places such as verifyInstruction, but that is not done here (it tends to catch errors earlier, but in reality just shows all the mir tests that have incorrect feature predicates). The interface was also simplified slightly, moving computeAvailableFeatures into the function so that it does not need to be called externally. The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently show errors in the test-suite, so have been disabled with FIXME comments. Recommitted with some fixes for the leftover MCII variables in release builds. Differential Revision: https://reviews.llvm.org/D129506
This reverts commit e2fb8c0f4b940e0285ee36c112469fa75d4b60ff as it does not build for Release builds, and some buildbots are giving more warning than I saw locally. Reverting to fix those issues.
D25618 added a method to verify the instruction predicates for an emitted instruction, through verifyInstructionPredicates added into <Target>MCCodeEmitter::encodeInstruction. This is a very useful idea, but the implementation inside MCCodeEmitter made it only fire for object files, not assembly which most of the llvm test suite uses. This patch moves the code into the <Target>_MC::verifyInstructionPredicates method, inside the InstrInfo. The allows it to be called from other places, such as in this patch where it is called from the <Target>AsmPrinter::emitInstruction methods which should trigger for both assembly and object files. It can also be called from other places such as verifyInstruction, but that is not done here (it tends to catch errors earlier, but in reality just shows all the mir tests that have incorrect feature predicates). The interface was also simplified slightly, moving computeAvailableFeatures into the function so that it does not need to be called externally. The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently show errors in the test-suite, so have been disabled with FIXME comments. Differential Revision: https://reviews.llvm.org/D129506