[Issue 10848] Compiler should always try to inlining a direct lambda call
https://issues.dlang.org/show_bug.cgi?id=10848 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 10848] Compiler should always try to inlining a direct lambda call
https://issues.dlang.org/show_bug.cgi?id=10848 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #10 from Steven Schveighoffer schvei...@yahoo.com --- *** Issue 14164 has been marked as a duplicate of this issue. *** --
[Issue 10848] Compiler should always try to inlining a direct lambda call
https://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #9 from github-bugzi...@puremagic.com 2013-12-30 11:53:27 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/1d4a493f58ef7c73feb804f48f6b6cf2af4200dd fix Issue 10848 - Compiler should always try to inlining a direct lambda call https://github.com/D-Programming-Language/dlang.org/commit/badd56670beb06c2b8a19bc73a4fca39673d0f64 Merge pull request #372 from 9rnsr/fix10848 [enh] Issue 10848 - Compiler should always try to inlining a direct lambda call -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #6 from Manu turkey...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #7 from Kenji Hara k.hara...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #8 from Manu turkey...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 Manu turkey...@gmail.com changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from Manu turkey...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848
--- Comment #2 from hst...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #4 from Kenji Hara k.hara...@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: ---
[Issue 10848] Compiler should always try to inlining a direct lambda call
http://d.puremagic.com/issues/show_bug.cgi?id=10848 --- Comment #5 from Kenji Hara k.hara...@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: ---
