freenode/#clasp - IRC Chatlog
Search
15:39:27
karlosz
is there anything explaining what all the differen boehm version are or what they do?
15:41:03
karlosz
so cclasp is the cleavir clasp, bclasp is the old compiler, and aclasp is a c++ interpreter?
15:55:56
drmeister
What this all means is it’s too complicated and too implementation dependent detail and needs to be swept away by image save/load
16:07:59
Bike
"I'm going to try removing the -flto-thin argument and try linking again" "Warning: execute-link-fasl worked after removing -flto from the argument list --- FIGURE OUT WHAT IS GOING WRONG WITH THAT ARGUMENT!!!"
16:11:57
drmeister
No worry unless things crash later. This is the linked crashing and then recovering.
17:53:15
karlosz
assert waf_node != None, "Could not find waf node for lisp file %s - did you run './waf update_dependencies'?" % file_name
18:01:45
Bike
drmeister: i made some changes, and now building asdf and serve event seems to hang, but if i do it through the workbench there's no problem. do you know what the difference could be?
19:43:20
Bike
i can load cleavir in bclasp, and functions compiled with it seem to work, even if they do weird things like have &optional and &key that i didn't think about before
19:53:17
karlosz
interesting, the commit that upgrades to llvm6 builds successfully and gets past linking on arch
20:35:13
karlosz
Bike: do you have a more full backtrace for the unitialized data problem you ran into with the closure conversion fix? i couldnt succeed getting the latest clasp to build
20:36:02
Bike
no. i can get you one if you want it. a backtrace might nto be sufficient since it's (probably) a miscompile, though.
20:42:55
karlosz
okay, sounds good. i also have partial inlining and closure conversion as the first two steps in my passes, so it should help narrow down where the possible problems could be from, considering it builds for me
20:50:48
karlosz
im looking through the clasp source a bit; its something that check-for-uninitialized-inputs-dumb doesnt catch?
20:52:37
karlosz
thats interesting, because i didnt tthink those could be iintroduced given that inlining is the only thing that happens beforehand
20:53:17
karlosz
if thats the case it shouldnt be too hard to fix, but i want a test case where the graph shows it
20:53:43
karlosz
sadly, that would also mean fixing closure conversion by adding ast nodes wont work
21:14:32
karlosz
oh hey. a little unrelated but partial inlining does something wonky and wrong with this (lambda (n)
21:20:43
karlosz
yeah. i dont think it should be too hard to fix. we just have to check the place we are unwinding to from the funcall is still inside the catch arm and redirect it to a call to error or something
21:22:54
karlosz
the flow structure in HIR doesnt actually match the flow graph of execution for non local exits
21:44:06
Bike
my reasoning was that the flow graph for nonlocal exits can't actually be statically determined- you can have unwind-protects intervening.
22:04:38
karlosz
hm. it seems like its really the funcalls in the catch arm that have two different continuations, rather than cthe catch instruction
22:18:36
karlosz
the last sentence is a bit presuptuous, i don't actually know if there is a situation that an instruction could be followed by some other instructions not explicitly listed in that description
22:19:32
karlosz
by that i mean like how the current catch instructions are clearly succeeded by instructions that don't actually succeed it in execution
22:20:36
karlosz
it could be the case that F always takes its normal control flow edge - that's okay, as long as we don't have any instruction executed after F that isnt a successor to it
22:53:57
karlosz
here is a concrete way in which it is an improvement: in the old model, the first funcall in the catch arm would not dominate the instruction it unwinds to
22:54:07
karlosz
in this model, if it dominates the instruction, it indeed dominates the instruction
23:16:18
karlosz
after thinking it over again, i don't think this will work. things like (funcall (funcall (block nil (lambda (x) (lambda () (return))))) would be too hard to analyze
23:16:30
karlosz
there is probably some better way to not make inlining make that ub case into a loop
23:22:57
stassats
you can do the equivalent of (let (exit) (block nil (prog1 (lambda () (when exit (error "out of scope")) (setf exit t) (return)) (setf exit t))))
0:12:39
karlosz
i think the instances where functions capturing continuations can get inlined at call site are also places where we have enough information to hot wire what would be the return into into an error
1:00:37
karlosz
so we probably need a new hir instruction that denotes a return to an out of scope tag
1:01:03
karlosz
just so that inlining can wire itself to some sort of error when it meets an illegal return