inlining...

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Thu Mar 20 18:39:52 PDT 2014


On Thursday, 20 March 2014 at 15:26:35 UTC, ponce wrote:
> Now after this, even if the inlining become harmful for other 
> reasons, I want this inlining to be maintained, whatever the 
> cost, not subject to random rules I don't know of. When you

The rules aren't random. The inliner conceptually use weighting 
anyway, you just increase the threshold for a specific call-tree. 
E.g. if a function is on the borderline of being inlined the 
probability is 50% if you add some noise to the selection with a 
magnitude that equals the "typical approximation error" of the 
heuristics. "inline(0.75)" should increase the probability to 
75%. Today all functions have an implied "inline(0.5)". I think 
you should have this kind of control for all compiler heuristics 
thresholds that are "arbitrary", not only inlining.

Call site inlining is primarily useful for inlining external 
code. The alternative is usually to replace libraries with your 
own version.


More information about the Digitalmars-d mailing list