digitalmars.D.bugs - [Issue 10848] New: Compiler should always try to inlining a direct lambda call
- d-bugmail puremagic.com (32/32) Aug 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (14/14) Aug 18 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (23/23) Aug 19 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (10/10) Aug 19 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (13/18) Aug 19 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (11/13) Aug 19 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (23/39) Aug 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (13/21) Aug 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
- d-bugmail puremagic.com (14/19) Aug 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10848
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 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: -------
Aug 18 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848 Manu <turkeyman gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |turkeyman gmail.com 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: -------
Aug 18 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848 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: -------
Aug 19 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull 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: -------
Aug 19 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848Sounds 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: -------
Aug 19 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848It 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: -------
Aug 19 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848Can 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.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.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: -------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.
Aug 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848Can 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: -------
Aug 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10848Yes, 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: -------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.
Aug 20 2013