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/
