[LLVMdev] Selectively Disable Inlining for Functions

[Michael McCracken]

On 3/7/06, Chris Lattner <sabre at nondot.org> wrote:
> 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.

I'm also curious to hear what your proposal will look like.
Fine-grained optimization control is something I've looked at somewhat
with my LENS project - essentially you would keep advice like this in
an external file, so that it doesn't change the source and because it
is stored with version metadata, a future version of the compiler
could notice that the advice was intended for an older version, and
issue a warning or ignore it.

Of course there are other practical problems with keeping separate
metadata files - it makes it harder to maintain drop-in compatibility
with build scripts, for instance. Also, in the case of using 'never
inline' for correctness, that probably does belong in the code.

-mike

--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/