On Tuesday, 3 February 2015 at 09:36:57 UTC, Walter Bright wrote:
On 2/3/2015 1:11 AM, Mike wrote:
All things being equal, will there be any difference between
the resulting
binaries for each of these scenarios?
No.
Another way of putting it: Does pragma(inline, true) simply
allow the user to
compiler parts of their source file with -inline?
Yes.
pragma(inline, false) paradoxically can be used to improve
performance. Consider:
if (cond)
foo();
else
bar();
If cond is nearly always false, then foo() is rarely executed.
If the compiler inlines it, it will likely take away registers
from being used to inline bar(), and bar() needs those
registers. By marking foo() as not inlinable, it won't consume
those registers. (Also, inlining foo() may consume much code,
making for a less efficient jump around it and making it less
likely for the hot code to fit in the cache.)
This is why I'm beginning to think a pragma(hot, true/false)
might be a better approach, as there are more optimizations
that can be done better if the compiler knows which branches
are hot or not.
I think you're misunderstanding each other.
As far as I understand it, Johannes doesn't care much about
inline for optimizations. He wants to easily access a fixed
memory location for MMIO. Now you're telling him to use
volatileLoad and volatileStore to do this which may work but only
has a bearable syntax if wrapped. But for his embedded work he
needs to be sure that the wrapping is undone and thus needs
either pragma(force_inline) or pragma(address).
You're against force_inline, but now you're moving the goal posts
by arguing against force_inline in the general case of code
optimization. But that's not the problem here, we're talking MMIO
with addresses embedded in the instruction stream.
Besides this: Why should a compiler that has an inliner fail to
inline a function marked with force_inline? The result may be
undesirable but it should always work at least?
