[LLVMdev] calling conventions and inlining

[Chris Lattner]

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote:
>> 
>>> As I've just seen that there are some things going on w.r.t the long 
>>> needed implementation of calling conventions, may I also ask if it's 
>>> possible to address inlining at the same moment (i.e. attributes 
>>> always_inline and noinline, but maybe LLVM wants a finer grained level 
>>> here) ?
>> 
>> They really are different issues.  inlining hints are really hints for the 
>> optimizer, where calling convention changes are required for correctness 
>> under some circumstances (e.g. to get proper tail calls).
>
> Well, strictly academically inlining is just an optimizer hint, but in 
> reality inlining also somewhat affects the "semantics" by changing code cache 
> utilization (which becomes more and more important these days).

I don't think it's academic at all.  It *is* an optimization hint.

>>> I'd be willing to spend some work on this, but I need the help/pre-work of 
>>> an expert for the actual bytecode and core classes modifications.
>> 
>> I'm not sure if we want to go this route.  Are there cases where the 
>> inliner is doing the wrong thing?  LLVM has traditionally avoided 
>> annotations for optimization hints like this, at least until there is some 
>> substantial policy change, I still think it's the right way to go.
>
> At least something for disabling inlining (attribute noinline) is needed, and 
> I had a feeling that such a change would nicely go along with the current 
> calling convention modifications (even if these are completely different 
> things).

I agree that noinline is important in some cases.  I think it would be 
very reasonable to teach the inliner to not inline functions that use the 
"coldcc" calling convention.  If you want to make this change, I would 
definitely accept it.  I don't think that there is any need to add an 
explicit "do not inline this" attribute though.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/