freenode/#sicl - IRC Chatlog
Search
9:22:04
|3b|
when generating code from eq-instruction, should i be looking at the predecessors of the instructions in the 2 branches to determine where they merge againi?
9:41:14
|3b|
and are there other situations (tagbody?) where an instruction would have multiple predecessors without a corresponding if-like instruction so i could just look at a stack of branches to see which is merging?
15:44:28
Bike
By "subject to capture" I meant (block name (f (lambda () (return-from name)))) where F is unknown. <- the dynamic environment doesn't have to be captured there, just the timestamp-like-part, which it already is, like we discussed
15:49:27
Bike
still need to pass the dynamic environment to calls, guess it can just be a normal argument...
16:51:05
Bike_
oh, and tagbody wouldn't need a successor to the end, there's no way to nonlocally enter there (unelss there's a tag at the end, in which case it would have one anyway)
20:30:29
drmeister
beach: I'm looking at improving performance in HIR processing. One of the things that I've been looking at for a while is the map-instructions-xxx functions. As you probably recall they use a hash-table to keep track of nodes that have been visited.
20:30:54
drmeister
In Clasp they rehash 8 or 9 times as they ramp up in size and then they are tossed away.
20:31:21
drmeister
I'm trying to measure the impact of this when I compile-file in parallel - with multiple threads ramping hash-tables like that.
20:32:01
drmeister
I've gone and changed clasp's hash tables to use open-addressing rather than chaining. It's easier to reason about their size that way.