digitalmars.D.bugs - [Issue 3490] New: DMD Never Inlines Functions that Could Throw
- d-bugmail puremagic.com Nov 09 2009
- d-bugmail puremagic.com Nov 09 2009
- d-bugmail puremagic.com Jul 08 2010
- d-bugmail puremagic.com Jul 08 2010
- d-bugmail puremagic.com Jul 09 2010
- Brad Roberts <braddr puremagic.com> Jul 09 2010
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: -------
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 --- 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: -------
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 --- 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: -------
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 | --- 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: -------
Jul 08 2010
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: -------
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 --- 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
Jul 09 2010









d-bugmail puremagic.com 