dmd commit, revision 497


user: walter

msg:
bugzilla 2008 Poor optimization of functions with ref parameters

http://www.dsource.org/projects/dmd/changeset/497

dsource.org wrote:
> dmd commit, revision 497
>
>
> user: walter
>
> msg:
> bugzilla 2008 Poor optimization of functions with ref parameters
>
> http://www.dsource.org/projects/dmd/changeset/497
>
> 

A couple other improvements to the inliner are possible:

1. inline functions with loops in them, as long as the place where they are inlined is a statement rather than an expression

2. always inline private functions that are called exactly once, even if they are large, if it is possible to inline them

On 5/21/2010 6:44 PM, Walter Bright wrote:
> 
> dsource.org wrote:
>> dmd commit, revision 497
>>
>>
>> user: walter
>>
>> msg:
>> bugzilla 2008 Poor optimization of functions with ref parameters
>>
>> http://www.dsource.org/projects/dmd/changeset/497
>>
>> 
> 
> A couple other improvements to the inliner are possible:
> 
> 1. inline functions with loops in them, as long as the place where they are inlined is a statement rather than an expression
> 
> 2. always inline private functions that are called exactly once, even if they are large, if it is possible to inline them

Yup.. 2008 wasn't the end, but the beginning.  I'm going to knock out as many of the reasons things aren't inlined as possible... in the fullness of time.

Cost should be the decider, not what's inside the function.

What are the inlining rules for delegates/lazy arguments when the delegate should be known at compile time? I'm porting some C++ code with a number of #define's that give the first half of a for loop. The body is naturally a delegate parameter, but performance is critical.

Sent from my iPhone

On May 21, 2010, at 9:44 PM, Walter Bright <walter at digitalmars.com> wrote:

>
>
> dsource.org wrote:
>> dmd commit, revision 497
>>
>>
>> user: walter
>>
>> msg:
>> bugzilla 2008 Poor optimization of functions with ref parameters
>>
>> http://www.dsource.org/projects/dmd/changeset/497
>>
>>
>
> A couple other improvements to the inliner are possible:
>
> 1. inline functions with loops in them, as long as the place where they are inlined is a statement rather than an expression
>
> 2. always inline private functions that are called exactly once,
> even if they are large, if it is possible to inline them
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

To inline, the source must be known. The best way to do that is the way std.algorithm does it - pass the delegate as an alias parameter to a template.

Jason House wrote:
> What are the inlining rules for delegates/lazy arguments when the delegate should be known at compile time? I'm porting some C++ code with a number of #define's that give the first half of a for loop. The body is naturally a delegate parameter, but performance is critical.
>
> Sent from my iPhone
>
> On May 21, 2010, at 9:44 PM, Walter Bright <walter at digitalmars.com> wrote:
>
>>
>>
>> dsource.org wrote:
>>> dmd commit, revision 497
>>>
>>>
>>> user: walter
>>>
>>> msg:
>>> bugzilla 2008 Poor optimization of functions with ref parameters
>>>
>>> http://www.dsource.org/projects/dmd/changeset/497
>>>
>>>
>>
>> A couple other improvements to the inliner are possible:
>>
>> 1. inline functions with loops in them, as long as the place where they are inlined is a statement rather than an expression
>>
>> 2. always inline private functions that are called exactly once, even
>> if they are large, if it is possible to inline them
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>