diff options
Diffstat (limited to 'llvm/lib/Transforms/IPO/FunctionSpecialization.cpp')
| -rw-r--r-- | llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | 39 |
1 files changed, 0 insertions, 39 deletions
diff --git a/llvm/lib/Transforms/IPO/FunctionSpecialization.cpp b/llvm/lib/Transforms/IPO/FunctionSpecialization.cpp index 1206d0a..2c1f5f6 100644 --- a/llvm/lib/Transforms/IPO/FunctionSpecialization.cpp +++ b/llvm/lib/Transforms/IPO/FunctionSpecialization.cpp @@ -5,45 +5,6 @@ // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===----------------------------------------------------------------------===// -// -// This specialises functions with constant parameters. Constant parameters -// like function pointers and constant globals are propagated to the callee by -// specializing the function. The main benefit of this pass at the moment is -// that indirect calls are transformed into direct calls, which provides inline -// opportunities that the inliner would not have been able to achieve. That's -// why function specialisation is run before the inliner in the optimisation -// pipeline; that is by design. Otherwise, we would only benefit from constant -// passing, which is a valid use-case too, but hasn't been explored much in -// terms of performance uplifts, cost-model and compile-time impact. -// -// Current limitations: -// - It does not yet handle integer ranges. We do support "literal constants", -// but that's off by default under an option. -// - The cost-model could be further looked into (it mainly focuses on inlining -// benefits), -// -// Ideas: -// - With a function specialization attribute for arguments, we could have -// a direct way to steer function specialization, avoiding the cost-model, -// and thus control compile-times / code-size. -// -// Todos: -// - Specializing recursive functions relies on running the transformation a -// number of times, which is controlled by option -// `func-specialization-max-iters`. Thus, increasing this value and the -// number of iterations, will linearly increase the number of times recursive -// functions get specialized, see also the discussion in -// https://reviews.llvm.org/D106426 for details. Perhaps there is a -// compile-time friendlier way to control/limit the number of specialisations -// for recursive functions. -// - Don't transform the function if function specialization does not trigger; -// the SCCPSolver may make IR changes. -// -// References: -// - 2021 LLVM Dev Mtg “Introducing function specialisation, and can we enable -// it by default?”, https://www.youtube.com/watch?v=zJiCjeXgV5Q -// -//===----------------------------------------------------------------------===// #include "llvm/Transforms/IPO/FunctionSpecialization.h" #include "llvm/ADT/Statistic.h" |