DIP56 Provide pragma to control function inlining

Tove tove at fransson.se
Sun Feb 23 16:21:23 PST 2014


On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
> I'm aware of that, but once you add the:
>
>     version(BadCompiler) { } else pragma(inline, true);
>
> things will never get better for BadCompiler. And besides, that 
> line looks awful.

If I need to support multiple compilers and if one of them is not 
good enough, I would first try to figure out which statement 
causes it to fail, if left with no other alternatives: Manually 
inline it in the common path for all compilers, _not_ create 
version blocks.

Inspecting asm output doesn't scale well to huge projects. 
Imagine simply updating the existing codebase to use a new 
compiler version.

Based on my experience, even if we are profiling and benchmarking 
a lot and have many performance based KPI:s, they will still 
never be as fine-grained as the functional test coverage.

Also not forgetting, some performance issues may only be detected 
in live usage scenarios on the other side of the earth as the 
developers doesn't even have access to the needed 
environment(only imperfect simulations), in those scenarios you 
are quite grateful for every static compilation error/warning you 
can get...

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.


More information about the Digitalmars-d mailing list