llvm dev - Mar 2006 - [LLVMdev] Selectively Disable Inlining for Functions

On Mar 6, 2006, at 4:05 PM, Chris Lattner wrote:
> On Mon, 6 Mar 2006, John Criswell wrote:
>> I was wondering if there is a standard way of specifying a list of  
>> functions that *should not* be inlined by the -inline pass.
>
> Nope, but you could hack something into gccas/gccld if you want.   
> Of course, you can disable inlining completely with the -disable- 
> inlining flag.
>
>> I'm currently working with an experimental analysis pass that  
>> checks for calls to memory allocation functions; inlining and dead  
>> code elimination might make the pass more stable, but we don't  
>> want to inline the calls to the memory allocation functions until  
>> after our analysis pass is finished.
>
> The simplest way is to change the heuristic to consider those  
> functions as expensive to inline.

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?


--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

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/

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/