freenode/#sicl - IRC Chatlog
Search
4:26:53
beach
OK, so I don't think dominance is the right way to determine where to put FETCH-INSTRUCTIONs for fetching constants.
4:28:30
beach
So I am thinking that the fetch should be replicated for each place where the constant is used. Then loop invariant optimization and redundancy optimization should be applied as appropriate.
6:12:52
beach
Because I don't apply any optimizations, the code contains a lot of unnecessary junk right now. That is not a problem per se, because the current priority is to generate native code. However, all that junk makes it hard to see what is going on in the IR visualizer.
6:17:28
beach
And it's the closer conversion that is responsible for putting FETCH-INSTRUCTIONs right after the ENTER; not the constant hoisting code.
6:18:33
beach
The constant-hoisting code just introduces shared lexical variables between the top-level function and the nested functions where the constants are used.
6:23:50
beach
Hmm, now I remember a discussion with Bike and karlosz concerning the use of cells for shared variables. The idea was to avoid cells in the closure when the closure does not modify the variable. But things are not that simple.
6:24:27
beach
Clearly, if the datum is a constant, it is put in the static environment of the closure once, and then never modified.
6:26:34
beach
The closure could be handed off to a separate thread, and the caller could simultaneously modify the variable, and the modification must then be visible in the closure.
6:29:51
beach
Then the resulting closure must contain a cell, even though X is not modified by the closure.
6:30:45
beach
This stuff is not going to be trivial to optimize, and for that reason, I think I'll just live with the additional junk for now and concentrate on HIR-to-MIR and MIR-to-LIR.
6:31:54
beach
Because if the closure is only called, and not handed over to a thread, then in some cases, no cell is needed.