[LLVMdev] Inline hints for *compiler clients*

[Vikram S. Adve]

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

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


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