[LLVMdev] Inlining

[Samuel Crow]

Hello Dustin,

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.)

Personally, I don't see the need for a preprocessor in most circumstances.  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).

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.  It would rest heavily on the type system remaining as it is (assuming it works the way I think it works) and it seems that Chris Lattner wants to change that.  Maybe it's a good thing our project is as far behind schedule as it is.  I'd better do some experimenting sometime with opaque types and inlines together to see if they work as expected for producing easy macros.


Anyway, sorry for drifting off-topic,

--Sam


----- Original Message ----
> From: Dustin Laurence <dllaurence at dslextreme.com>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Sat, January 9, 2010 12:35:33 PM
> Subject: Re: [LLVMdev] Inlining
> 
> On 01/09/2010 10:00 AM, Samuel Crow wrote:
> > 
> > Always inline is the closest to a preprocessor macro you can get in
> > LLVM Assembly since it doesn't have a preprocessor at all.
> 
> Mine does. :-)
> 
> > ...LLVM does
> > aggressive inlining for functions used only once so those instances
> > don't require specification as alwaysinline.
> 
> What I'm trying to do is understand the practical use cases.  Concrete
> example: I have some little type accessor and conversion functions that
> are typically two or three instructions long because all they really do
> is manipulate tag data in the low-order bits of pointers.  (I'm not
> exactly innovative, am I?)  While small, they are called all over the
> place for boxing and unboxing language-level objects.  In C they would
> be explicitly inline.  What is the LLVM equivalent?
> 
> My guess is the optimizer will always inline such tiny functions no
> matter what as it's probably both a space and a time win, so maybe I
> need a different example.  Suppose they were typically five, or ten, or
> twenty, or forty instructions long?  Who is responsible for deciding on
> the advisability of inlining?  The front-end (which in this case is
> actually me?)?  That would be the equivalent of the C99/C++ 'inline'
> compiler hint.  Or in LLVM is it better not to give manual compiler
> hints about inlining in most cases and let the optimizers decide?
> 
> I suppose it's a fuzzy question because I'm fishing for intended usage,
> not just semantics.
> 
> Dustin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev