[LLVMdev] Selectively Disable Inlining for Functions

[Chris Lattner]

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 
> mechanism?

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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/