libera/#sicl - IRC Chatlog

10:33:49 beach With the planned AST transformations, the only operator that creates functions will be LABELS. So I can do an escape analysis by checking which function names appear in an argument position of a function call.

10:34:05 beach There can be some false positives that way, but probably very few.

10:34:14 beach And I can make a call graph where the nodes are functions and the arcs are calls. Any function that does not escape and that is not in a cycle of that graph can have its environment shared with its parent function. To indicate that fact, I can re-introduce LETs which will now always introduce temporary variables that will not be closed over.

10:34:21 beach Another transformation I can do at the AST level and that is currently done at the HIR level is making argument parsing more explicit. For that, every &OPTIONAL and &KEY parameter is replaced by two lexical variables, one for the parameter itself and one for a "supplied-p" parameter, but no initforms.

10:34:23 beach Code in the body of the function checks the supplied-p parameter to determine whether to evaluate the initform of the original lambda list. Code in the body also binds the original lambda-list parameters according to whether they are lexical or special variables.

10:36:43 beach After escape analysis and environment merge has taken place, I can introduce LETs for nested function calls, so that each function calls has only variables as arguments.

10:37:02 beach *each function call

10:38:39 beach I haven't given much thought yet to things I can do with lexical non-local control transfers from TAGBODY/GO and BLOCK/RETURN-FROM, but I will.

10:40:43 beach I don't get much feedback related to these ideas, so I don't know whether my descriptions are understandable, whether they represent good ideas, etc. So I guess the only way to figure out whether they are good ideas or not is to try them out.

10:41:49 beach And I am improving the AST visualizer, because I think it is actually doable to visualize ASTs of fairly complex functions and get an idea about what they do, as opposed to HIR graphs that very quickly become too large to understand.

10:59:03 beach Hmm, I can make a command in the visualizer for each of the transformations I implement. That way I can see the result directly.

10:59:19 hayley My own compiler/IR likes to make an absolute mess at some point between inlining and peepholing.

11:03:55 hayley But perhaps there'll be another mess once I lower the HIR :)

11:15:02 hayley Speaking of, I've come up with two project ideas for next year, and I'm trying to guess which would be more viable. One is to investigate my gut feeling that I can make a thread-local GC scheme based on my (mostly-)non-moving generational collector. Another is to investigate how complex of a "typed assembly language" one needs to target in order to support certain compiler optimisations.

11:18:52 hayley The former seems more straightforward, but I'm a bit tired of writing garbage collectors honestly. <https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html> mentions that many attacks on the V8 JavaScript engine involve tricking the compiler into incorrectly removing bounds checks, so the latter seems relevant to real problems.

13:31:45 edgar-rft hayley: it might feel moar creative to write garbage creators

13:48:22 hayley I've written a few of those. Though making a new benchmark suite (or working how to scale up cl-bench for modern hardaare) could be fun.

13:51:06 hayley For example, I'm not so sure if boehm-gc would trigger more than one collection in SBCL, because the heap is much larger by default. (I made it generate larger trees for my paper; there's a very handy parameter for that.)

13:52:49 hayley The DaCapo benchmark suite was accompanied by a paper describing how the benchmarks are quantitatively different. I remember a graph of the distribution of pointer distances, which reinvented a study decades before on Interlisp.