freenode/#clasp - IRC Chatlog
Search
22:44:57
drmeister
I'm generalizing the exception handling code I wrote for bclasp so that I can use it for cclasp. That will make backtrace frames easier to install.
5:55:32
Bike
hi beach. i tried path replication to eliminate boolean assignments. seems to work, though there are some kludges i'll ahve to unkludge
6:06:59
Bike
well, the problem i had with (if (if (primop:whatever ...) t nil) ...) was that recognizing constants is a little difficult. so i moved up to generally (if (if ...) ...). because of how ast-to-hir works, that results in a test where each branch ends in an output to a temporary, which is then used as an input to an eq test
6:07:32
Bike
so, for each eq instruction it checks if either of its inputs are only defined twice, and that the two instructions defining that variable share a successor.
6:09:30
Bike
no. if the shared successor doesn't dominate the eq, it's possible to reach the eq while one of its inputs is undefined, so something went pretty wrong.
6:12:30
Bike
i figured it was kind of a fairly easy case, since without doing let-uninitialized the only way to get this hir is by (if (if ...) ...). and in actual code there's two or three instructions at most between eq and the shared successor, so there's not a lot to replicate.
6:20:17
Bike
i guess this might make it useful to run type inference more than once. should figure out how to do that well
6:21:59
Bike
in this case path replication -> inference -> inference again since some paths were cut
6:23:54
Bike
in this case i had (if (consp x) (car x)). that results in typeq cons -> eq -> typeq cons. path replication plus inference cuts out the eq to make it typeq cons typeq cons, which type inference can deal with
6:40:59
Bike
you have six blocks, T, TL, TR, E, EL, ER. T -> TL -> E, T -> TR -> E, E -> EL, E -> ER. T is the typeq test, E is the eq test. EL has another typeq in it. When inference is run first, when it reaches E it can't assume anything from T since both branches of the typeq end there. once you propagate constants, you can eliminate E, leaving you with T -> TL -> EL and T -> TR -> ER. now the typeq in EL has
6:48:00
Bike
if you apply path replication you get a duplicate E. So T -> TL -> E1 and T -> TR -> E2, and E1 -> EL, E1 -> ER, E2 -> EL, E2 -> ER
6:48:12
beach
I am interested in understanding how doing type inference twice without any transformation between the two can be advantageous.
6:48:53
Bike
then type inference removes the actual eqs in E1 and E2, along with one of the successors.
6:55:39
beach
That makes me wonder whether there are other cases where running the inference twice (with or without path replication) would be advantageous.
6:56:20
beach
And it makes me wonder whether running it twice is enough, or whether it should be repeated until no more transformation is accomplished.
6:58:54
Bike
kinda funny you say that though. yesterday when i was doing eliminate superfluous temporaries, i didn't make it as good as it could be, and on some basic example i had to run it five times before it couldn't eliminate any more
7:05:18
Bike
i think another example with types would be... (if (typeq (if (test) a b) ...) (typeq ...)). has the same block structure
7:15:41
Bike
i guess a more general path replication check would be an input to a test being defined by both predecessors to some instruction, and nothing between that instruction and the test outputting to one of the test's inputs