[LLVMdev] Inline hints for *compiler clients*

[Chris Lattner]

On Wed, 15 Mar 2006, Vikram S. Adve wrote:
> [I've changed the subject to make this a new thread.]
>
> While all of this makes sense to me, note that Markus and John were asking 
> about different situations.  Markus was asking about user-written source 
> code.  John was asking about a compiler pass or tool written by a compiler 
> developer, not a user.
>
> These arguments apply to users but not compiler developers.  What do you 
> think about the latter?

Why can't the compiler pass just call InlineFunction(CallSite) on the 
callsite it wants inlined?  The only way that can fail is if LLVM cannot 
ever inline the call (e.g. it uses varargs).

-Chris

> On Mar 7, 2006, at 12:35 PM, Chris Lattner 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.
>> 
>> -Chris
>> 
>> -- 
>> http://nondot.org/sabre/
>> http://llvm.org/
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

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