On Thu, 2007-09-06 at 19:23 +1000, skaller wrote: > I'm thinking of changing procedures so they can return values.
It's done, as follows: 1. FIRST ORDER: The algorithm only eliminates direct applications, it does not eliminate applications whose argument is not a function constant, eg it won't eliminate applications of closures in HOF's unless the HOF has been inlined and the argument function is also inlined. THEREFORE at this point, the algorithm does NOT completely eliminate functions .. in fact the ones it fails to eliminate (HOF arguments) are the ones we probably want to eliminate most. 2. COMPLETE: The algorithm eliminates ALL direct applications, which is a bad idea because fully unravelled code will be slower and use more memory. This is because C++ compilers aren't smart enough to do good enough data flow analysis to optimise the code well. Compilers do better with expressions because anonymous (temporary) function results are .. well they're anonymous so the data flow is trivial. This is especially true I think for functions which would resolve to C functions. So actually the current algorithm may degrade performance. It remains to be more selective what functions are eliminated, eg based on if the function tries to do a svc call or maybe if it uses the collector (in which case we may want to run the collection at any allocation point .. we couldn't do that before because the stack got in the way and we have no way to trace the stack (s .. in the case of multi-threading). The big ADVANTAGE of being non-selective at the moment is debugging -- more fodder for the algorithm will expose more cases of food poisoning. 3. LATE: The process is applied AFTER the inlining optimisation and monomorphisation passes. This means function specific inlining stuff eg tail-rec handling, etc, is still done as before. Those processi <sic> have some good chance of flattening function applications out into procedural code anyhow, and probably produce better results, so they go first. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
