diff options
author | Slava Zakharin <szakharin@nvidia.com> | 2024-03-13 08:23:10 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-03-13 08:23:10 -0700 |
commit | 732f5368cdc297e83f8720fb13a8c848ff116ccf (patch) | |
tree | 6891bcfcae702dd553b6d91015a109b731c0d738 /clang/lib/Basic/Module.cpp | |
parent | 096ee4e16fd62cd578d20ec4e8ad4756f4e369ee (diff) | |
download | llvm-732f5368cdc297e83f8720fb13a8c848ff116ccf.zip llvm-732f5368cdc297e83f8720fb13a8c848ff116ccf.tar.gz llvm-732f5368cdc297e83f8720fb13a8c848ff116ccf.tar.bz2 |
[RFC][mlir] Add profitability callback to the Inliner. (#84258)
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>
Diffstat (limited to 'clang/lib/Basic/Module.cpp')
0 files changed, 0 insertions, 0 deletions