http://d.puremagic.com/issues/show_bug.cgi?id=10848

           Summary: Compiler should always try to inlining a direct lambda
                    call
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: performance, spec
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: k.hara.pg@gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-18 18:50:33 PDT ---
Example code:

  void main() @safe {
    int n;
    auto p = (ref n)@trusted{ return &n; }(n);
  }

Command line:

  dmd test.d

does not inline the immediate lambda call. It would make performance penalty.

And, such lambda call is sometimes necessary for marking specific system operation as @trusted.

---

I think the D spec should mention about the case like as follows:

"If a function literal is immediately called, compiler always try to inline the call expression in-place."

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848


Manu <turkeyman@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |turkeyman@gmail.com


--- Comment #1 from Manu <turkeyman@gmail.com> 2013-08-18 23:51:35 PDT ---
Sounds like a good case for a __forceinline attribute, and then apply it implicitly in this case. This situation could leverage the same internal mechanic.

I still have MANY places where I want to guarantee inlining of certain functions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848



--- Comment #2 from hsteoh@quickfur.ath.cx 2013-08-19 19:38:26 PDT ---
It would be nice if this also applied to opApply that basically uses a single loop:

    class C {
        int opApply(scope void delegate(ref T iter) dg) {
            setupLoop(); // some simple setup code
            foreach (e; getInternalData()) {
                auto ret = dg(e);
                if (ret) return ret;
            }
            cleanupLoop(); // some simple cleanup code
        }
    }

    void main() {
        auto c = new C;
        foreach (e; c) {
            // opApply really should just be inlined here.
        }
    }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #3 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-19 20:34:43 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2483

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848



--- Comment #4 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-19 20:47:41 PDT ---
(In reply to comment #1)
> Sounds like a good case for a __forceinline attribute, and then apply it implicitly in this case. This situation could leverage the same internal mechanic.

"forceinline" is misleading word.

This proposal *does not* guarantee that the generated code is always inlined. If the given lambda body is too large/complex, or compiler's inlining ability is very little, the generated code may not be inlined. The language spec should allow it.

> I still have MANY places where I want to guarantee inlining of certain functions.

Inlining would increase compilation time. Such places should be defined carefully.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848



--- Comment #5 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-19 21:02:53 PDT ---
(In reply to comment #2)
> It would be nice if this also applied to opApply that basically uses a single loop:

To make expand opApply foreach useful, it would need two-level inlining. (first is for the call of opApply, second is for the call of the scope delegate)

I can imagine that in most case it would introduce generated code bloat. Therefore I think it should be treated by the -inline switch without any special treatment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848



--- Comment #6 from Manu <turkeyman@gmail.com> 2013-08-20 05:53:27 PDT ---
(In reply to comment #4)
> (In reply to comment #1)
> > Sounds like a good case for a __forceinline attribute, and then apply it implicitly in this case. This situation could leverage the same internal mechanic.
> 
> "forceinline" is misleading word.
> 
> This proposal *does not* guarantee that the generated code is always inlined. If the given lambda body is too large/complex, or compiler's inlining ability is very little, the generated code may not be inlined. The language spec should allow it.

Can you give an example of where the compiler is unable to inline code?
I don't see why any single function with the source available shouldn't
technically be inlinable. If you're writing a function that's more like a macro
(but not a mixin, ie, shouldn't pollute/interfere with containing scope), it
may be useful... but yes, sure it's generally true that when code gets too
large, there becomes very few compelling reasons to inline.

> > I still have MANY places where I want to guarantee inlining of certain functions.
> 
> Inlining would increase compilation time. Such places should be defined carefully.

It not really a matter of care, I use it where it's a requirement.

That's why I'd suggest the keyword should be '*force*inline'; this suggests the programmer deliberately made the request, and knows exactly what they're doing. It's not an attribute that makes any guarantees about performance, and shouldn't be considered an optimisation. It's about fine control in terms of code generation.

I thought this was an interesting parallel. In the case you present here, or in cases where you may have an algorithm that iterates a loop block implemented as a lambda in some particular way, I can't imagine a situation where you would ever want that lambda to not inline. But there are also many low level function I need to explicitly mark too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848



--- Comment #7 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-20 08:25:20 PDT ---
(In reply to comment #6)
> Can you give an example of where the compiler is unable to inline code?
> I don't see why any single function with the source available shouldn't
> technically be inlinable. If you're writing a function that's more like a macro
> (but not a mixin, ie, shouldn't pollute/interfere with containing scope), it
> may be useful... but yes, sure it's generally true that when code gets too
> large, there becomes very few compelling reasons to inline.

Yes, theoretically such an immediately called lambda would be able to be inlined always. But, if the compiler does not have any inlining feature, inlining would fail.

AFAIK, current D spec does not have any mention about inlining. Today it is always compiler implementation-specific feature. Therefore spec should not *guarantee* the generated code quality.

> That's why I'd suggest the keyword should be '*force*inline'; this suggests the programmer deliberately made the request, and knows exactly what they're doing.

Explicit "forceinline" code annotation is completely irrelevant topic.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10848



--- Comment #8 from Manu <turkeyman@gmail.com> 2013-08-20 17:32:36 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > That's why I'd suggest the keyword should be '*force*inline'; this suggests the programmer deliberately made the request, and knows exactly what they're doing.
> 
> Explicit "forceinline" code annotation is completely irrelevant topic.

Yes, as I said, I mentioned it because I felt it could share some code here. If there was a 'forceinline' concept known by the compiler, you could implicitly mark lambda's in your situation with this same new attribute, and it would reliably do what you want, in addition to offering the keyword to control it explicitly... rather than just making some sort of hack in the compiler to do it for lambda's in particular situations.

It was just a thought. If I'm wrong, then no problem. It just seemed like it could be tidier.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------