summaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/CodeGenTargetMachineImpl.cpp
AgeCommit message (Collapse)Author
2025-07-10Reland "[CodeGen] Expose the extensibility of PassConfig to plugins (#139059)"Tcc100
Add missing dependencies to unittest target Original patch broke BUILD_SHARED bots and required revert #147947
2025-07-10Revert "[CodeGen] Expose the extensibility of PassConfig to plugins" (#147947)Jan Patrick Lehr
Reverts llvm/llvm-project#139059 This broke https://lab.llvm.org/buildbot/#/builders/10/builds/9125/steps/8/logs/stdio The bot does a SHARED_LIBS=ON build. I can reproduce locally with the CMake cache file in offload/cmake/caches/AMDGPUBot.cmake as the build config.
2025-07-10[CodeGen] Expose the extensibility of PassConfig to plugins (#139059)Tcc100
This PR exposes the backend pass config to plugins via a callback. Plugin authors can register a callback that is being triggered before the target backend adds their passes to the pipeline. In the callback they then get access to the `TargetMachine`, the `PassManager`, and the `TargetPassConfig`. This allows plugins to call `TargetPassConfig::insertPass`, which is honored in the subsequent `addPass` of the main backend. We implemented this using the legacy pass manager since backends still use it as the default.
2025-07-08Triple: Record default exception handling typeMatt Arsenault
Currently the default exception handling type is scattered across the backends in MCAsmInfo constructors. Allow this to be computed from the triple so the IR can centrally determine the set of ABI calls. Manually submitting, closes #147225
2025-06-26Triple: Forward declare Twine and remove include (#145685)Matt Arsenault
2025-04-26[TTI] Simplify implementation (NFCI) (#136674)Sergei Barannikov
Replace "concept based polymorphism" with simpler PImpl idiom. This pursues two goals: * Enforce static type checking. Previously, target implementations hid base class methods and type checking was impossible. Now that they override the methods, the compiler will complain on mismatched signatures. * Make the code easier to navigate. Previously, if you asked your favorite LSP server to show a method (e.g. `getInstructionCost()`), it would show you methods from `TTI`, `TTI::Concept`, `TTI::Model`, `TTIImplBase`, and target overrides. Now it is two less :) There are three commits to hopefully simplify the review. The first commit removes `TTI::Model`. This is done by deriving `TargetTransformInfoImplBase` from `TTI::Concept`. This is possible because they implement the same set of interfaces with identical signatures. The first commit makes `TargetTransformImplBase` polymorphic, which means all derived classes should `override` its methods. This is done in second commit to make the first one smaller. It appeared infeasible to extract this into a separate PR because the first commit landed separately would result in tons of `-Woverloaded-virtual` warnings (and break `-Werror` builds). The third commit eliminates `TTI::Concept` by merging it with the only derived class `TargetTransformImplBase`. This commit could be extracted into a separate PR, but it touches the same lines in `TargetTransformInfoImpl.h` (removes `override` added by the second commit and adds `virtual`), so I thought it may make sense to land these two commits together. Pull Request: https://github.com/llvm/llvm-project/pull/136674
2025-04-10MCAsmStreamer: Replace the MCInstPrinter * parameter with unique_ptrFangrui Song
... to clarify ownership, aligning with other parameters. Using `std::unique_ptr` encourages users to manage `createMCInstPrinter` with a unique_ptr instead of a raw pointer, reducing the risk of memory leaks. * llvm-mc: fix a leak and update llvm/test/tools/llvm-mc/disassembler-options.test * #121078 copied the llvm-mc code to CodeGenTargetMachineImpl and made the same mistake. Fixed by 2b8cc651dca0c000ee18ec79bd5de4826156c9d6 Using unique_ptr requires #include MCInstPrinter.h in a few translation units. * Delete a createAsmStreamer overload I deprecated in 2024 * SystemZMCTargetDesc.cpp: rename to `createSystemZAsmStreamer` to fix an overload conflict. Pull Request: https://github.com/llvm/llvm-project/pull/135128
2025-04-09:createMCStreamer: delete InstPrinter on errorFangrui Song
2025-04-08[llc] Add -M for InstPrinter optionsFangrui Song
For many targets, llvm-objdump and llvm-mc (https://reviews.llvm.org/D103004) support -M no-aliases (e.g. `RISCVInstPrinter::applyTargetSpecificCLOption`). This patch implements -M for llc. While here, rename "DisassemblerOptions" in llvm-mc to the more appropriate "InstPrinterOptions". For llvm-mc --assemble, there is no disassembler involved. Pull Request: https://github.com/llvm/llvm-project/pull/121078
2024-11-14Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)Matin Raayai
Following discussions in #110443, and the following earlier discussions in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html, https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine` interface classes. More specifically: 1. Makes `TargetMachine` the only class implemented under `TargetMachine.h` in the `Target` library. 2. `TargetMachine` contains target-specific interface functions that relate to IR/CodeGen/MC constructs, whereas before (at least on paper) it was supposed to have only IR/MC constructs. Any Target that doesn't want to use the independent code generator simply does not implement them, and returns either `false` or `nullptr`. 3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming aims to make the purpose of `LLVMTargetMachine` clearer. Its interface was moved under the CodeGen library, to further emphasis its usage in Targets that use CodeGen directly. 4. Makes `TargetMachine` the only interface used across LLVM and its projects. With these changes, `CodeGenCommonTMImpl` is simply a set of shared function implementations of `TargetMachine`, and CodeGen users don't need to static cast to `LLVMTargetMachine` every time they need a CodeGen-specific feature of the `TargetMachine`. 5. More importantly, does not change any requirements regarding library linking. cc @arsenm @aeubanks