inlining...
duh
nothx at yahoo.com
Fri Mar 14 01:19:37 PDT 2014
> Something always tells me this is the compilers job... What
> clever reasoning are you applying that the compiler's inliner
> can't? It seems like a different situation to say SIMD code,
> where correctly structuring loops can require a lot of
> gymnastics that the compiler can't or won't (floating point
> conformance) do. The inlining decision seems easily automatable
> in comparison.
>
> I understand that unoptimised builds for debugging are a
> problem, but a sensible compiler let's you hand pick your
> optimisation passes.
>
> In short: why are compilers not good enough at this that the
> programmer needs to be involved?
No compiler gets this right 100% of the time, so if it is the
compilers job they are failing. Most C++ compilers will sometimes
require use of forceinline with SSE intrinsics.
Unless it has PGO support the compiler has no idea about the
runtime usage of that code. It wouldn't know which code the
program spends 90% of its time in so it just applies general
heuristics when deciding to inline.
What I'd like is the ability to set a inline level per function.
Something like 0 being always inline, and 10 being never inline.
Unless specified otherwise, the default would be 5
So if you want forceinline behavior
inline(0) vec3 dot(vec3 a, vec3 b); //always inlined
inline(10) vec3 cross(vec3 a, vec3 b); //never inlined
And override it at callsite--
inline(10) auto v = dot(a,b);
More information about the Digitalmars-d
mailing list