Search
Tuesday, 10th of October 2017, 16:59:34 UTC
17:09:48
scymtym
stassats: can you try this http://paste.lisp.org/display/358231 ?
17:19:11
stassats
scymtym: that succeeds
17:19:38
scymtym
i see some scary differences on x86_64 as well
17:20:08
scymtym
it might have just spilled everything with the broken change
17:20:46
scymtym
i wish we had a way to track changes in compiler output
17:20:57
stassats
i have an idea how to do that
17:22:00
stassats
first prerequisite, serializing IR
17:22:18
scymtym
i'm going to test some more and then push the potential fix
17:22:29
stassats
then, load up the compiler, go through all functions in SB-C, and instrument
17:22:35
stassats
record the changes with each function call
17:22:36
scymtym
so we can run later phases on canned ir1 examples?
17:22:50
stassats
then a tool that visualizes everything (the hardest part)
17:23:21
stassats
scymtym: that could be arranged as well
17:24:14
scymtym
i had some success with mcclim for visualizing compilery things
17:24:27
stassats
first, a simple IR visualizer needs to be written (i'm thinking about doing one in JS), then a time-travelling one
17:25:54
scymtym
will the time-travelling one require non-destructive phases? or would you make snapshots?
17:26:26
stassats
on each function call go through the component and find changes to the IR
17:26:52
stassats
record them and the function that made them
17:27:17
stassats
with a call tree as well
17:27:26
stassats
so, basically, a profiler
17:29:14
scymtym
could also add tracing (in the model transformation sense): from which other ir objects has a given object been derived and by which operation. but you probably thought of that
19:25:48
stassats
looks like i'm able to fix a stack-analyze problem not by deleting an aver, but by doing better dead code elimination
19:26:23
stassats
(although semantically the aver is not right)
19:33:05
stassats
but optimizing and fixing a bug in one go is nicer
Wednesday, 11th of October 2017, 4:59:34 UTC