www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3490] New: DMD Never Inlines Functions that Could Throw

reply d-bugmail puremagic.com writes:
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



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: -------
Nov 09 2009
next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Nov 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jul 08 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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                         |



---
undoing false dependency

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 08 2010
prev sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3490




PDT ---

 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: -------
Jul 09 2010
parent Brad Roberts <braddr puremagic.com> writes:
On 7/9/2010 6:17 AM, d-bugmail puremagic.com wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3490
 
 
 

PDT ---

 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
Jul 09 2010