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