digitalmars.D.bugs - [Issue 3490] New: DMD Never Inlines Functions that Could Throw
- d-bugmail puremagic.com (44/44) Nov 09 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3490
- d-bugmail puremagic.com (15/15) Nov 09 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3490
- d-bugmail puremagic.com (13/13) Jul 08 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3490
- d-bugmail puremagic.com (11/11) Jul 08 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3490
- d-bugmail puremagic.com (9/10) Jul 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3490
- Brad Roberts (18/31) Jul 09 2010 Replying outside bugzilla, no reason to clutter up all those reports wit...
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=3490 PDT ---undoing false dependencyCan 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
On 7/9/2010 6:17 AM, d-bugmail puremagic.com wrote:http://d.puremagic.com/issues/show_bug.cgi?id=3490 PDT ---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, Bradundoing false dependencyCan you elaborate a little on why having bug 859 as a tracker of all missing inline oportunities is a bad thing? Thanks
Jul 09 2010