H1 2015 Priorities and Bare-Metal Programming

Tobias Pankrath via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 3 01:47:58 PST 2015


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?




More information about the Digitalmars-d mailing list