## Purpose This patch is one in a series of code-mods that annotate LLVM’s public interface for export. This patch annotates the remaining LLVM CodeGen and CodeGenTypes library interfaces that were missed in, or modified since, previous patches. The 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). ## Overview The bulk 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 following manual adjustments were also applied after running IDS: - Explicitly instantiate `CallLowering::setArgFlags` template method instances in `CodeGen/GlobalISel/CallLowering.h` and annotate them with `LLVM_ABI`. These methods are already explicitly instantiated in `lib/CodeGen/GlobalISel/CallLowering.cpp` but were not `extern` declared in the header. - Annotate several explicit template instantiations with `LLVM_EXPORT_TEMPLATE`. - Include `llvm/CodeGen/Passes.h` from `llvm/lib/CodeGen/GlobalMergeFunctions.cpp` to pick up the declaration of `llvm::createGlobalMergeFuncPass` with the `LLVM_ABI` annotation (instead of adding `LLVM_ABI` to the function definition in this file) ## 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
## Purpose This patch prepares the llvm/CodeGen library for public interface annotations in support of an LLVM Windows DLL (shared library) build, tracked in #109483. The purpose of this patch is to make the upcoming codemod of this library more straight-forward. It is not expected to impact any functionality. The `LLVM_ABI` annotations will be added in a subsequent patch. These changes are required to build with visibility annotations using Clang and gcc on Linux/Darwin/etc; Windows DLL can build fine without them. ## Overview This PR does four things in preparation for adding `LLVM_ABI` annotations to llvm/CodeGen: 1. Explicitly include `Machine.h` and `Function.h` headers from `MachinePassManager.cpp` so that `Function` and `Machine` types are available for the instantiations of `InnerAnalysisManagerProxy`. Without this change, Clang only will only export one of the templates after visibility annotations are added to them. Unclear if this is a Clang bug or expected behavior, but this change avoids the issue and should be harmless. 2. Refactor the definition of `MachineFunctionAnalysisManager` to its own header file. Without this change, it is not possible to add visibility annotations to the declaration with causing gcc to produce `-Wattribute` warnings. 3. Remove the redundant specialization of the `DominatorTreeBase<MachineBasicBlock, false>::addRoot` method. The specialization is the same as implemented in `DominatorTreeBase` so should be unnecessary. Without this change, it is not possible to annotate the subsequent instantiations of `DominatorTreeBase` in the header file without gcc producing `-Wattribute` warnings. Mark unspecialized `addRoot` as `inline` to match the removed specialized version. 4. Move the explicit instantiations of the `GenericDomTreeUpdater` template earlier in the header file. These need to appear before being used in the `MachineDomTreeUpdater` class definition or gcc will produce warnings once visibility annotations are added. ## Background The LLVM Windows DLL effort is tracked in #109483. Additional context is provided in [this discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307). Clang and gcc handle visibility attributes on explicit template instantiations a bit differently; gcc is pickier and generates `-Wattribute` warnings when an explicit instantiation with a visibility annotation appears after the type has already appeared in the translation unit. These warnings can be avoided by moving explicit template instantiations so they always appear first. ## 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
Invalidation is already handled in the passes loop for MFAM, so all of the rest analyses are preserved. (See `PassManager::run()`) This won't change the number of invalidations, but will prevent needless `MFAM::Invalidator::invalidate()` invocations made by results depending on other results (since the invalidate shorts if `<AllAnalysesOn<MF>>` is preserved)
In new pass system, `MachineFunction` could be an analysis result again, machine module pass can now fetch them from analysis manager. `MachineModuleInfo` no longer owns them. Remove `FreeMachineFunctionPass`, replaced by `InvalidateAnalysisPass<MachineFunctionAnalysis>`. Now `FreeMachineFunction` is replaced by `InvalidateAnalysisPass<MachineFunctionAnalysis>`, the workaround in `MachineFunctionPassManager` is no longer needed, there is no difference between `unittests/MIR/PassBuilderCallbacksTest.cpp` and `unittests/IR/PassBuilderCallbacksTest.cpp`.
Like ModuleToFunctionPassAdaptor. --------- Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Currently the new PM infra for codegen puts everything into a MachineFunctionPassManager. The MachineFunctionPassManager owns both Module passes and MachineFunction passes, and batches adjacent MachineFunction passes like a typical PassManager. The current MachineFunctionAnalysisManager also directly references a module and function analysis manager to get results. The initial argument was that the codegen pipeline is relatively "flat", meaning it's mostly machine function passes with a couple of module passes here and there. However, there are a couple of issues with this as compared to a more structured nesting more like the optimization pipeline. For example, it doesn't allow running function passes then machine function passes on a function and its machine function all at once. It also currently requires the caller to split out the IR passes into one pass manager and the MIR passes into another pass manager. This patch rewrites the new pass manager infra for the codegen pipeline to be more similar to the nesting in the optimization pipeline. Basically, a Function contains a MachineFunction. So we can have Module -> Function -> MachineFunction adaptors. It also rewrites the analysis managers to have inner/outer proxies like the ones in the optimization pipeline. The new pass managers/adaptors/analysis managers can be seen in use in PassManagerTest.cpp. This allows us to consolidate to just having to add to one ModulePassManager when using the codegen pipeline. I haven't added the Function -> MachineFunction adaptor in this patch, but it should be added when we merge AddIRPass/AddMachinePass so that we can run IR and MIR passes on a function before proceeding to the next function. The MachineFunctionProperties infra for MIR verification is still WIP.
The MachineFunctionAnalysisManager forward declaration is messing with upcoming changes.
With the legacy pass manager, MachineModuleInfoWrapperPass owned the MachineModuleInfo used in the codegen pipeline. It can do this since it's an ImmutablePass that doesn't get invalidated. However, with the new pass manager, it is legal for the ModuleAnalysisManager to clear all of its analyses, regardless of if the analysis does not want to be invalidated. So we must move ownership of the MachineModuleInfo outside of the analysis (this is similar to PassInstrumentation). For now, make the PassBuilder user register a MachineModuleAnalysis that returns a reference to a MachineModuleInfo that the user owns. Perhaps we can find a better place to own the MachineModuleInfo to make using the codegen pass manager less cumbersome in the future.
This pass should be the last machine function pass in pipeline, also ignore `PI.runAfterPass(*P, MF, PassPA);` to avoid accessing a dangling reference.
This commit adds `runBeforePass`/`runAfterPass` for machine module pass so `llc -debug-pass-manager` can e.g., print module pass names. Part of #69879.