freenode/#clasp - IRC Chatlog
Search
23:41:31
selwyn
yeah i got that earlier. i thought it went away, but it turns out that i actually built the latest clasp with AST - i just realised
23:43:55
selwyn
could it be due to not having distclean'd? it's what i assumed when i saw it and indeed i hadn't
23:45:56
Bike
https://github.com/robert-strandh/SICL/blob/87eb4fead5c65eaa5b8954ca2f7fa47cf5dd08e8/Code/Cleavir/CST-to-AST/convert.lisp#L17
23:48:21
Bike
it matches the backtrace too, that method is the last function before the error basically
23:51:05
karlosz
this is why i stuck with cherry picking the patches i made - even loading sicl in clisp broke a couple of things recently
23:59:23
Bike
well i was going to make more cleavir changes tomorrow anyway, so i can update it with that
23:59:41
Bike
related, if anyone knows what name i should use for the multiple-value-setq-prog1 thing, now's the time
2:29:53
karlosz
and reinitialize-data on top of the inlining function bar can go away, and so can set predecessors next to inlining-function
2:31:05
karlosz
patch for getting rid of both forthcoming after this build finishes, but its at 90/445 and hasn't died yet
2:31:54
drmeister
My laptop ran out of power in the middle of ASDF build - and it hung up - so I'm starting it again.
11:03:46
selwyn
i built in 1h51 just now - basically no change. i wonder if i did something wrong? asdf did take a while
11:06:30
drmeister
I don't know - timing can be tricky. The flame graphs show improvements in inlining.
11:07:13
drmeister
Do you mean what is the difference between the CST compiler and the AST compiler?
11:08:26
drmeister
A couple of things - (1) the CST compiler tracks source locations for every expression. Source information is propagated all the way from where the source is read down to the object files.
11:09:49
drmeister
(2) The CST compiler fixes a subtle bug in the AST compiler that I still don't really appreciate - I think it's with closed over environments.
11:10:26
drmeister
In fixing that bug it generates code where LET statements are expanded into calls to functions. This slows down the generated code significantly (by a factor of 2 or so).
11:11:07
drmeister
The solution is to do a lot more inlining at the HIR level to improve the generated code performance.
11:11:24
drmeister
That inlining code is what we are dealing with now - it slows the compiler down a lot.
11:12:31
drmeister
So we crawl through this valley of slowness to come out the other side with a better compiler.
11:13:02
drmeister
The next big thing to do is value numbering, type inference and removal of dead code.
11:14:13
selwyn
right. i have to go now, i will read the logs and be back in a couple of hours. thanks for explanation