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."
Comment #1 by turkeyman — 2013-08-18T23:51:35Z
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.
Comment #2 by hsteoh — 2013-08-19T19:38:26Z
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.
}
}
(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.
Comment #5 by k.hara.pg — 2013-08-19T21:02:53Z
(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.
Comment #6 by turkeyman — 2013-08-20T05:53:27Z
(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.
Comment #7 by k.hara.pg — 2013-08-20T08:25:20Z
(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.
Comment #8 by turkeyman — 2013-08-20T17:32:36Z
(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.
Comment #9 by github-bugzilla — 2013-12-30T11:53:27Z