• Martin Nowak (7/7) Jan 02 2015 I'm currently working on optimizing the GC marking code and I'm
• ZombineDev (15/22) Jan 02 2015 DIP56[1] proposes to use pragmas to control inlining.
• Benjamin Thaut (6/7) Jan 02 2015 +1. You have my vote when it comes to more percise inline controls. I'm
• safety0ff (7/9) Jan 02 2015 It's rare to get measurable gains from __builtin_expect, and
• Walter Bright (9/11) Jan 02 2015 The dmd optimizer assumes that for:

"Martin Nowak" <code dawg.eu> writes:

I'm currently working on optimizing the GC marking code and I'm 
having quite some problems with the inline decisions of the 
compiler.
The compiler can't make good decisions here, because it lacks 
information about which branches are executed rarely.
Would be nice to have  noinline,  forceinline and 
__builtin_expect.

"ZombineDev" <valid_email he.re> writes:

DIP56[1] proposes to use pragmas to control inlining.

However, AFAIU, you can't override them on the caller-side and it 
does not specify how it interacts with header (.di) files and 
shared libraries (I guess like C/C++).
The proposal also mentions that these pragmas are not function 
attributes because they should not affect the semantics of the 
function. However I am not entirely sure that this is correct 
because if use alloca, depending on if you inline or not, you can 
get a stack overflow. There were two[2, 3] bug fixes in dmd 
related to that.

[1]: http://wiki.dlang.org/DIP56
[2]: https://github.com/D-Programming-Language/dmd/pull/3811
[3]: https://github.com/D-Programming-Language/dmd/pull/3961 (fix 
of the previous PR)

On Friday, 2 January 2015 at 14:34:39 UTC, Martin Nowak wrote:
 I'm currently working on optimizing the GC marking code and I'm 
 having quite some problems with the inline decisions of the 
 compiler.
 The compiler can't make good decisions here, because it lacks 
 information about which branches are executed rarely.
 Would be nice to have  noinline,  forceinline and 
 __builtin_expect.

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 02.01.2015 um 15:34 schrieb Martin Nowak:
 Would be nice to have  noinline,  forceinline and __builtin_expect.

+1. You have my vote when it comes to more percise inline controls. I'm 
still not able to use -inline with my projects because it triggers some 
code-gen bug I was not able to reduce yet.

Kind Regards
Benjamin Thaut

"safety0ff" <safety0ff.dev gmail.com> writes:

On Friday, 2 January 2015 at 14:34:39 UTC, Martin Nowak wrote:
 Would be nice to have  noinline,  forceinline and 
 __builtin_expect.

It's rare to get measurable gains from __builtin_expect, and 
since there is no macro preprocessor in D, it's likely less 
verbose to just put the common case as the first branch since 
most compilers use that for static branch prediction (with the 
same effect on resulting machine code as __builtin_expect.)

Just my 2c.

Walter Bright <newshound2 digitalmars.com> writes:

On 1/2/2015 6:34 AM, Martin Nowak wrote:
 The compiler can't make good decisions here, because it lacks information about
 which branches are executed rarely.

The dmd optimizer assumes that for:

    if (e)
       e1;
    else
       e2;

that e1 is executed more often than e2. Of more interest, though, is not 
inlining very rarely executed code, because it will cause suboptimal register 
allocation.