[LLVMdev] Inlining

[Dustin Laurence]

On 01/09/2010 11:21 AM, Samuel Crow wrote:

> Alwaysinline is not a hint.  It forces something inline that wouldn't
> have otherwise been as long as the linkage type permits it.  (You
> just ran into a situation where linkage did not permit it.)

Understood.  I am just wondering if one should generally trust the
optimizer, or if it's better to manually insist on inlining functions
that should obviously be inlined.

My guess is for normal usage you trust the optimizer, and use
alwaysinline for unusual things you know need inlining but the optimizer
can't figure it out (say inlining an over-large function into a tight
inner loop in your star formation hydrodynamics code)?

> Personally, I don't see the need for a preprocessor in most
> circumstances.

I suspect that's because in spite of my funny questions your brain
refused to believe that I am doing something as deranged as writing a
non-trivial interpreter for a "real" language in raw IR with a text
editor, and so you assumed I was doing something sane instead. :-)  I
challenge you to write LLVM IR with only Stone Knives, Bearskins, a text
editor, and llvm-as (and make or anything else you like as long as it
doesn't manipulate the source unless you build the tool starting with
the Stone Knives) as well engineered as I can with preprocessor help (in
this case, simple, brain-dead CPP because it's available and m4 is
simply not to be contemplated).  Seriously--I don't think it can be
done, so if you do it then I'd learn a lot.

In essence, I am the manual front-end.  I'm not as consistent and
predictable as a normal one, but I like to think I make better dinner
conversation. :-)

> ...If you need to do type substitution you can use an
> opaque type.  The only reason for conditional compilation is if you'd
> need to be able to generate inline assembly for the host (which
> shouldn't ever be absolutely necessary in LLVM except for legacy
> code).

Um...*everything* for me is the equivalent of inline IR for you.  Note
well that I make absolutely no claims that it is *necessary* in any way,
however. :-)

I admit I don't really understand opaque types yet, but they won't do
what I need down here with my primitive Stone Tools.  The single biggest
wins were the simple ability to #include (same reason as in C: I can
have separate source modules whose interfaces are type-checked) and to
define constants to parametrize the code with certain choices (it's
awful nice not to have things like the tagged representation of nil
hard-coded a hundred places in the code, as I found out when I realized
I'd made the wrong choice).  Conditional compilation and parametrized
macros are OK but not as vital.

> One thing I wanted to do with the language we're developing is to do
> a custom template-like function involving always-inlines containing
> opaque types.

And will that have the Turing-completeness of C++ templates? :-D  My
advice is not to use angle brackets....

Dustin