On 08/08/2012, at 8:15 AM, john skaller wrote: > I have confirmed there is a bug in the recursion detection algorithm. > Well actually not a bug so much as a design fault.
BTW: there's another bug in the same algorithm: it doesn't detect unused children correctly. When I set Sexpr's str function to inline, stuff no longer blows up, but some used children get deleted leading to subsequent error where an reference to one of them is reported not found. Setting List's str function to noinline as well fixes this. It's not clear how to repair the inlining algorithm, it's very sensitive to the exact order or doing things and small details of how they're done. The algorithm is intrinsically non-functional and very nasty due to heavy recursion. Replacing it with a more controllable set of passes will defeat its ability to inline stuff well. Other compilers have done this, for example MLton does lots of easy to manage passes. MLton produces good results, but Felix is much better at inlining -- when the algorithm actually works. One way to simplify the algorithm would be to monomorphise first. This doesn't get rid of cloning for parameter to argument specialisation, although it does get rid of type specialisation, and it also allows 100% removal of virtual functions *prior* to inlining. Currently Felix inlines, using the same algorithm, both before AND after monomorphisation. The algorithm is specially constructed to support polymorphic inlining, even though Felix (more or less) can not take advantage of that at this time since it doesn't support intensional polymorphism -- except in some special cases. however it might in the future, in two ways: first by actual intensional polymorphism (as done by C using void*, and which it can in theory do right now), and secondly by generating templates (which are extensional, but from the point of view of the compiler the output is actually polymorphic). Generating polymorphic code is essential for "down to the nuts and bolts" separate compilation (and particularly fully compiled binary code in plugins). The bottom line is: I want to defer rewriting the algorithm, its too much work at the moment. Some other issues demand attention (such as handling tuples and sums of arbitrary size with library code instead of compiler intrinsics or library hacks that only handle a finite number of cases). The theory of function call graphs seems missing. I have no idea why it seems no research has been done on such a fundamental topic. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
