On Tue, 7 Mar 2006, Markus F.X.J. Oberhumer wrote:> Still, my approach makes the inline hint a first-class property of an LLVM
> function just like the calling convention, including preserving full source
> code information.
Preserving full source code information isn't a goal of LLVM, at least if
you don't count debug information. :)
> Most of the patch is actually boring infrastructure, and you will note that
> the actual consultation of the hints in InlineSimple.cpp is just a few
lines
> leaving much room for further improvements.
Yup.
>> Here are the specific problems with your patch that I see:
>>
>> 1. ExplicitInline/ImplicitInline are currently ignored. These fall
into
>> the class of dangerous information that is hard to use in a
>> meaningful way. For example just becase a method is defined in the
>> body of a class, it doesn't tell you anything about its
potential for
>> inlining: huge methods can be there too. I think that using this
>> information is extremely dangerous.
>
> Well, I didn't need to exploit that info for my purposes, that's
why it says
> "FIXME" in the patch.
I understand that. My point above is that there doesn't seem to be a good
way to *use* this information. Inline markers are essentially arbitrary:
people use them to affect linkage as much as they do to mark things they
want actually inlined. Except for the always and never inline cases, I
think that structural analysis of the code will always be more useful than
"it was defined in a class body" or "the user used inline".
>> 3. As implemented, your 'never inline' option has a significant
problem:
>> it does not disable IPO of the function. In particular, one reason
>> that people want to disable inlining is so that there is a
well-known
>> entry-point to the function. If the function isn't inlined, but
>> arguments are deleted, this capability breaks.
>
> Yes, this is on purpose. But you can use both __attribute__((noinline)) and
> __attribute__((used)) for disabling IPO.
Fair enough.
>> As a specific proposal to provide "never inline" in a way
that is
>> low-impact on LLVM and solves #3, I suggest that we add a new
>> llvm.neverinline global array variable (like the llvm.used global).
This
>> global would point to all neverinline functions, and would have
appending
>> linkage (like llvm.used).
>
> This is an implementation issue, but I wonder if we should use too many of
> those "magic" arrays instead of using proper attributes.
The nice thing about the magic arrays are that they don't require explicit
IR support to keep updated and they do not require memory for functions
that don't use them (adding a field to Function would increase the space
usage for all Functions).
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
