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