DIP56 Provide pragma to control function inlining

Walter Bright newshound2 at digitalmars.com
Sun Feb 23 17:05:56 PST 2014


On 2/23/2014 4:21 PM, Tove wrote:
> Inspecting asm output doesn't scale well to huge projects. Imagine simply
> updating the existing codebase to use a new compiler version.

Again, this is treating 'inline' as being the only optimization that matters? 
It's not even the most important - that would likely be register allocation.

At some point, you're going to need to trust the compiler.


> You are right in that there is nothing special about inlining, but I'd rather
> add warnings for all other failed optimisation opportunities than not to warn
> about failed inlining. RVCT for instance has --diag_warning=optimizations, which
> gives many helpful hints, such as alias issues: please add "restrict", or
> possible alignment issues etc.

There are *thousands* of optimization patterns. Logging which ones were applied 
to each expression node would be utterly useless to anyone but a compiler 
writer. (You can turn this on in debug builds of the compiler and see for yourself.)

The most effective log is to look at the asm output. There isn't a substitute. I 
know that doesn't scale, going back to my point that at some point you're going 
to have to spot check here and there and otherwise trust the compiler.

I know that most programmers don't want to look at the asm output. Whether an 
error for failed inlining is or is not issued won't change the need to have a 
look now and then, if you want your code to be the fastest it can be.

BTW, although the DIP says the compiler can ignore it, in practice there aren't 
going to be perverse compilers. Compiler writers want their compilers to be 
useful, and don't go out of their way to sneakily interpret the spec to do as 
bad a job as possible. Conversely, the history of programmer-supplied optimizer 
edicts (see 'register') is not a very good one, as programmers are often not 
terribly cognizant of the tradeoffs and tend to use overly simplistic rules when 
applying these edicts. As optimizers improve, they shouldn't be impeded by 
well-intentioned but wrong optimization edicts.

(An early version of my C compiler had a long list of various optimization 
strategies that could be turned on/off. Never once was any appropriate use made 
of these. It's why dmd has evolved to simply have -O. -inline is a separate 
switch for reasons of symbolic debuggability.)


More information about the Digitalmars-d mailing list