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