DIP56 Provide pragma to control function inlining

[Dmitry Olshansky]

24-Feb-2014 01:53, 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.

You actually going against yourself with this argument - for porting you 
typically suggest:

version(OS1)
  ...
else version(OS2)
  ...
else
static assert(0);

Why forced_inline is any different then other porting (where you want 
fail fast).
>>> 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.

Let's not detract from original point. ROL is done as an instrinsic, and 
there are different answers to many of these questions that are BETTER 
then _always_ triple checking by hand and doing re-writes. Switch may 
benefit from pragmas as well, and modern compiler allow tweaking it. In 
fact LLVM allows assigning weights to specify which cases are more probable.

Almost all of listed issues could be addressed better then dancing 
around disassembler and trying to please PARTICULAR COMPILER for many 
cases you listed above.

Yes, looking at ASM is important but no not every single case should 
require the painful cycle of:
compile->disassemble-->re-write-->compile-->...

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

Your nice tired and true way of doing things is EQUALLY FRAGILE (if not 
more) and highly coupled to the compiler but only SILENTLY so.

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

Like I don't know already, getting in this discussion.

> (Speaking from considerable experience doing that.)

And since you've come to enjoy it as is, you accept no improvements over 
that process? So you known it's hard fighting the compiler and you 
decidedly as a samurai reject any help messing with it. I seriously 
don't get the point.

GCC has force inline, let's look at what GCC does with its always_inline:
http://gcc.gnu.org/ml/gcc-help/2007-01/msg00051.html

Quote of interest:

---

 > **5) Could there be any situation, where a function with always_inline
 > is _silently_ not embedded?

I hope not.  I don't know of any.

---

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

Just because there are other reasons to look at disassembly is not a 
good reason to forcibly send people to double-check compiler for basic 
inlining.

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

And you accept no safe-guards against this because that is "the true old 
way"?

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

On the contrary, at least I may have to spent less time checking that 
intended optimizations are being done in ASM listings.

-- 
Dmitry Olshansky