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