summaryrefslogtreecommitdiff
path: root/mlir/lib/Transforms/InlinerPass.cpp
AgeCommit message (Collapse)Author
2025-08-26NFC: remove some instances of deprecated capture (#154884)Jeremy Kun
``` warning: implicit capture of 'this' with a capture default of '=' is deprecated [-Wdeprecated-this-capture] ``` Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com>
2025-08-23[MLIR] Adopt LDBG() macro in mlir/lib/Transforms/... (NFC)Mehdi Amini
2025-01-20Remove unnecessary return in InlinerPass.cpp (#123507)Hyunsung Lee
`void InlinerPass::runOnOperation()` doesn't need to have `return;` at the end of the procedure.
2024-04-02[mlir][inliner] Assert that no external nodes passed to the profitability ↵Slava Zakharin
hook. (#85489) Fixes #85400
2024-04-02[mlir][pass] Add `errorHandler` param to `Pass::initializeOptions` (#87289)Ivan Butygin
There is no good way to report detailed errors from inside `Pass::initializeOptions` function as context may not be available at this point and writing directly to `llvm::errs()` is not composable. See https://github.com/llvm/llvm-project/pull/87166#discussion_r1546426763 * Add error handler callback to `Pass::initializeOptions` * Update `PassOptions::parseFromString` to support custom error stream instead of using `llvm::errs()` directly. * Update default `Pass::initializeOptions` implementation to propagate error string from `parseFromString` to new error handler. * Update `MapMemRefStorageClassPass` to report error details using new API.
2024-03-23[mlir][inliner] Return early if the inliningThreshold is 0U or -1U. (#86287)Fabian Tschopp
Computing the inlinling profitability can be costly due to walking the graph when counting the number of operations. This PR addresses that by returning early if the threshold is set to never or always inline.
2024-03-13[RFC][mlir] Add profitability callback to the Inliner. (#84258)Slava Zakharin
Discussion at https://discourse.llvm.org/t/inliner-cost-model/2992 This change adds a callback that reports whether inlining of the particular call site (communicated via ResolvedCall argument) is profitable or not. The default MLIR inliner pass behavior is unchanged, i.e. the callback always returns true. This callback may be used to customize the inliner behavior based on the target specifics (like target instructions costs), profitability of the inlining for further optimizations (e.g. if inlining may enable loop optimizations or scalar optimizations due to object shape propagation), optimization levels (e.g. -Os inlining may be quite different from -Ofast inlining), etc. One of the questions is whether the ResolvedCall entity represents enough of the context for the custom inlining models to come up with the profitability decision. I think we can start with this and extend it as necessary. --------- Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
2024-03-06[mlir][inliner] Refactor MLIR inliner pass and utils. (#84059)Slava Zakharin
This is just code refactoring done as a preparation for adding MLIR inliner cost model hook(s). Related discussion: https://discourse.llvm.org/t/inliner-cost-model/2992 The logic of SCC-based MLIR inliner is separated into the Inliner implementation. The MLIR inliner pass becomes, well, just a pass that invokes the SCC-based MLIR inliner.