[LLVMdev] Selectively Disable Inlining for Functions
sabre at nondot.org
Tue Mar 7 10:35:13 PST 2006
On Tue, 7 Mar 2006, Vikram S. Adve wrote:
> Changing the heuristics directly would have to be a custom change (i.e.,
> couldn't be checked in). Is there a way for a client pass or tool to
> influence the heuristics? If not, does it make sense to add such a
To be clear, I'll restate my position here, then follow up with more
specifics of such a mechanism to Markus' email.
My basic position is that I think it's a bad thing to let the user have
fine grained control over optimizations at the source level. Being able
to say "always force this to be inlined" will make less or more sense as
the compiler evolves. In particular, as the compiler gets better at
improving code, the decision about what to inline will change, and code
that uses thes attributes won't (the authors of the code are unlikely to
revisit the attributes after they are written).
As one particularly pointed example, the code that uses attributes like
'always inline' are typically written and tuned for GCC, often for old
versions of it. GCC and LLVM (obviously) have very very very different
optimization capabilities (e.g. LLVM can do interprocedural inlining, dead
argument elimination, interprocedural constant prop, etc), and forcing
something to be inlined for GCC has a very different impact than does
forcing LLVM to inline it.
The meta problem with this is that the code will still *work*, it will
just perform more poorly than it should. As such, people are very
unlikely to revisit these attributes after they are initially written.
The above is a description of why I think that "always inline" is a bad
idea to support. However, I *do* [now] support the notion of "never
inline". In contrast with "always inline", never inline sometimes isn't a
performance hint: it can be a correctness hint and is far more invariant
across compiler versions than always inline is. While it can obviously be
abused, I think the chances for its abuse are reduced.
I will respond to Markus' mail with a concrete proposal for how this
could be implemented.
More information about the llvm-dev