Unfortunately, there are two `KCFI` passes in source tree,
`CodeGen/KCFI.cpp` and `Transforms/Instrumentation/KCFI.cpp`, use
`MachineKCFIPass` for machine function pass.
`MIRProfileLoaderPass` is resolved to the legacy one when
`LLVM_ENABLE_MODULES=ON`, use `MIRProfileLoaderNewPass` as a workaround.
This change broke building LLVM with Module support enabled, i.e.
`LLVM_ENABLE_MODULES=ON`.
This reverts commit f40da072ed51ba77bf46191b35a74208b1045042.
This reverts commit 16c8f6e91344ec9840d6aa9ec6b8d0c87a104ca3 with fix.
-Wswitch catched an unhandled enum value due to recent commits in
TargetPassConfig.cpp.
This reverts commit 94427af60c66ffea655a3084825c6c3a9deec1ad (relands
4646de5d75cfce3da4ddeffb6eb8e66e38238800 with fix).
Use "return std::move(AsmStreamer);" instead of "return AsmStreamer;" in
LVMTargetMachine::createMCStreamer. Unlike Clang, GCC seems having trouble
inserting a implicit lvalue->rvalue conversion.
Following up on D67687.
Please refer to the RFC here http://lists.llvm.org/pipermail/llvm-dev/2020-July/143309.html
`CodeGenPassBuilder` is the NPM counterpart of `TargetPassConfig` with below differences.
- Debugging features (MIR print/verify, disable pass, start/stop-before/after, etc.) living in `TargetPassConfig` are moved to use PassInstrument as much as possible. (Implementation also lives in `TargetPassConfig.cpp`)
- `TargetPassConfig` is a polymorphic base (virtual inheritance) to build the target-dependent pipeline whereas `CodeGenPassBuilder` is the CRTP base/helper to implement the target-dependent pipeline. The motivation is flexibility for targets to customize the pipeline, inlining opportunity, and fits the overall NPM value semantics design.
- `TargetPassConfig` is a legacy immutable pass to declare hooks for targets to customize some target-independent codegen layer behavior. This is partially ported to TargetMachine::options. The rest, such as `createMachineScheduler/createPostMachineScheduler`, are left out for now. They should be implemented in LLVMTargetMachine in the future.
Reviewed By: arsenm, aeubanks
Differential Revision: https://reviews.llvm.org/D83608
This reverts commit 31ecf8d29d81d196374a562c6d2bd2c25a62861e.
This reverts commit 3fdaa8602a086a3fca5f0fc8527536ac659079d0.
There is laying violation for Target->CodeGen.
Following up on D67687.
Please refer to the RFC here http://lists.llvm.org/pipermail/llvm-dev/2020-July/143309.html
`CodeGenPassBuilder` is the NPM counterpart of `TargetPassConfig` with below differences.
- Debugging features (MIR print/verify, disable pass, start/stop-before/after, etc.) living in `TargetPassConfig` are moved to use PassInstrument as much as possible. (Implementation also lives in `TargetPassConfig.cpp`)
- `TargetPassConfig` is a polymorphic base (virtual inheritance) to build the target-dependent pipeline whereas `CodeGenPassBuilder` is the CRTP base/helper to implement the target-dependent pipeline. The motivation is flexibility for targets to customize the pipeline, inlining opportunity, and fits the overall NPM value semantics design.
- `TargetPassConfig` is a legacy immutable pass to declare hooks for targets to customize some target-independent codegen layer behavior. This is partially ported to TargetMachine::options. The rest, such as `createMachineScheduler/createPostMachineScheduler`, are left out for now. They should be implemented in LLVMTargetMachine in the future.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D83608
