Inlining problems again

[Iain Buclaw]

On 4 April 2014 14:42, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 04/04/14 15:14, Johannes Pfau wrote:
>> Am Fri, 04 Apr 2014 11:52:13 +0200
>> schrieb Artur Skawina <art.08.09 at gmail.com>:
>>
>>> Built latest gcc4-8-based gdc (fdf0c614) today; immediately ran into
>>> this:
>>>
>>> Which is much more reasonable, and shouldn't require such hacks.
>>> I thought that inlining /templated/ functions across modules already
>>> worked; is this a different problem, and, more importantly, is it
>>> fixable?
>
>> Please try to reduce such examples in the future ;-)
>
> Sorry. Yes, I should have tried harder.
>
> [I'm probably subconsciously avoiding going near any phobos code... :)]
>
>
>> http://goo.gl/SJ0iEq
>> http://goo.gl/ykumCI
>>
>> @property bool empty(T)(in T[] a) @safe pure nothrow
>>
>> it's the 'in' which causes inlining to fail (const also fails).
>
> Hmm, I remember const-args were a problem in the past, but I had
> thought this was already fixed.
>

The switch -fdump-ipa-inline is your friend here:

---
Inline summary for D main/3 inlinable
  self time:       22
  global time:     0
  self size:       14
  global size:     0
  min size:       0
  self stack:      0
  global stack:    0
    size:4.000000, time:2.778000, predicate:(true)
    size:3.000000, time:2.000000, predicate:(not inlined)
  calls:
    writeln/27 function not considered for inlining
      loop depth: 0 freq: 389 size: 3 time: 12 callee size:12 stack: 0
    empty/26 mismatched arguments
      loop depth: 0 freq:1000 size: 4 time: 13 callee size: 2 stack: 0
---

Reason for no inline is "mismatched arguments" - which means that the
caller and callee disagree on the arguments to pass to the function.
The fix is to make sure that caller and callee arguments match when
generating the function on both sides.  We could prevent this from
recurring by putting in an assert in the codegen.