WebAssembly: Stop changing MCAsmInfo's ExceptionsType based on flags (#146343) 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.
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.