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

           Summary: DMD Never Inlines Functions that Could Throw
           Product: D
           Version: 2.036
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Keywords: performance
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: dsimcha@yahoo.com


--- Comment #0 from David Simcha <dsimcha@yahoo.com> 2009-11-09 06:26:18 PST ---
Here's an absurdly simple test program.  enforceStuff() does not get inlined, as the disassembly below shows.  I couldn't find anything about exceptions in inline.c, but if this doesn't get inlined, I assume nothing that could throw ever does.

This severely affects the performance of std.range, since Andrei uses enforce()
all over the place, causing lots of stuff not to be inlined.  For example, I
read disassemblies involving std.range.Take and it seems like Take.popFront()
and Take.front() are never inlined.

void main() {
    enforceStuff(1);
}

void enforceStuff(uint num) {  // Not inlined.
   if(num == 0) {
       throw new Exception("");
   }
}

Disassembly of main():

__Dmain PROC NEAR
;  COMDEF __Dmain
        push    eax                                     ; 0000 _ 50
        mov     eax, 1                                  ; 0001 _ B8, 00000001
        call    _D5test812enforceStuffFkZv              ; 0006 _ E8,
00000000(rel)
        xor     eax, eax                                ; 000B _ 31. C0
        pop     ecx                                     ; 000D _ 59
        ret                                             ; 000E _ C3
__Dmain ENDP

-- 
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=3490


Ary Borenszweig <ary@esperanto.org.ar> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ary@esperanto.org.ar


--- Comment #1 from Ary Borenszweig <ary@esperanto.org.ar> 2009-11-09 06:32:37 PST ---
Here's why:

int Statement::inlineCost(InlineCostState *ics)
{
    return COST_MAX;        // default is we can't inline it
}

and ThrowStatement never overrides it.

-- 
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=3490


Leandro Lucarella <llucax@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax@gmail.com
             Blocks|                            |859


--- Comment #2 from Leandro Lucarella <llucax@gmail.com> 2010-07-08 06:54:15 PDT ---
I'm marking this a a blocker of bug 859 so there is a single bug to track all the inlining issues. Please do the same if you open more bugs associated to inlining, or post them directly in bug 859.

-- 
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=3490


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com
             Blocks|859                         |


--- Comment #3 from Brad Roberts <braddr@puremagic.com> 2010-07-08 22:47:07 PDT ---
undoing false dependency

-- 
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=3490



--- Comment #4 from Leandro Lucarella <llucax@gmail.com> 2010-07-09 06:14:20 PDT ---
(In reply to comment #3)
> undoing false dependency

Can you elaborate a little on why having bug 859 as a tracker of all missing inline oportunities is a bad thing?

Thanks

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

On 7/9/2010 6:17 AM, d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=3490
> 
> 
> 
> --- Comment #4 from Leandro Lucarella <llucax@gmail.com> 2010-07-09 06:14:20 PDT ---
> (In reply to comment #3)
>> undoing false dependency
> 
> Can you elaborate a little on why having bug 859 as a tracker of all missing inline oportunities is a bad thing?
> 
> Thanks
> 

Replying outside bugzilla, no reason to clutter up all those reports with more stuff unrelated to the specifics of the reports themselves.

Using a real report as a tracker is almost always a bad idea.  Using this case as an example and assuming that 859 was an inlining bug:  What's the right thing to do when 859's issue is fixed but all the rest aren't?  If it wasn't a tracker, the right thing would be to close 859 and move on.  But trackers should only be closed when all the depends-on's are fixed.  See the problem?

The next reason that it's a bad idea is that 859 isn't a missed inline opportunity.  The code in question is inlined.  Something else in in play -- still looking into it.  So, fixed or not, the depend-on's aren't accurate any more either.. or at least some aren't.

I'm also of the general opinion that trackers aren't generally useful either,
but in this case it goes beyond that.  Inlining bugs are easy to locate with the
search feature.. just search for all bugs with inline in the subject.  Done.  Easy.

That help?

Later,
Brad