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