DIP56 Provide pragma to control function inlining

[Walter Bright]

On 2/23/2014 1:04 PM, Dmitry Olshansky wrote:
> That programmer is instantly aware that it can't be done due to some reason.
> Keep in mind that code changes with time and running profiler/disassembler on
> every tiny change to make sure the stuff is still inlined is highly
> counter-productive.

I'm aware of that, but once you add the:

     version(BadCompiler) { } else pragma(inline, true);

things will never get better for BadCompiler. And besides, that line looks awful.


>> By the time you get to the point of checking on inlining, you're already
>> looking at the assembler output, because the function is on the top of
>> the profile of time wasters, and that's how you take it to the next
>> level of performance.
>
> A one-off activity. Now what guarantees you will have that it will keep getting
> inlined? Right, nothing.

You're always going to have that issue when optimizing at that level, and it 
will be for a large range of constructs. For example, you may need variable x to 
be enregistered. You may need some construct to be implemented as a ROL 
instruction. You may need a switch to be implemented as a binary search.


>> The trouble with an error message, is what (as the user) can you do
>> about it?
> Re-write till compiler loves it, that is what we do today anyway. Else we
> wouldn't mark it as force_inline in the first place.

In which case there will be two code paths selected with a version(BadCompiler). 
I have a hard time seeing the value in supporting both code paths - the 
programmer would just use the workaround code always.


> With error - yo get a huge advantage - an _instant_ feedback that it doesn't do
> what you want it to do. Otherwise it gets the extra pleasure of running
> disassembler to pinpoint your favorite call sites or observing that your
> profiler shows the same awful stats.

My point is you're going to have to look at the asm of the top functions on the 
profiler stats anyway, or you're wasting your time trying to optimize the code. 
(Speaking from considerable experience doing that.) There's a heluva lot more to 
optimizing effectively than inlining, and it takes some back-and-forth tweaking 
source code and looking at the assembler. I gave some examples of that above.

And yes, performance critical code often suffers from bit rot, and changes in 
the compiler, and needs to be re-tuned now and then.

I suspect if the compiler errors out on a failed inline, it'll be much less 
useful than one might think.