libera/#sicl - IRC Chatlog
Search
3:21:09
beach
hayley: When you are less busy, could you have a look at the infinite computation in register allocation? What you need to do is to run the bootstrapping script, and then do (let ((*features* '(:sicl))) (load-asdf-system '#:ctype *e5*)).
3:23:00
beach
Now that I think about it, pairwise.lisp took a while to load even without register allocation, so maybe it's just that it's taking a very long time.
3:26:33
hayley
Well, I closed the debugger and it didn't get stuck, nor did it feel like it took a while to load.
3:33:44
hayley
There were 93 elements in the stack of the work list, and 121 elements in the to-process table. Then I let register allocation continue for a few seconds. Then there were still that many elements in the stack and table.
3:48:56
hayley
I modified the register allocation code to print out which instructions it was allocating for (after having processed a million instructions), and it appears to loop between an ENTER-INSTRUCTION and MEMREF2-INSTRUCTION.
3:50:48
hayley
Also, I think my initial success with loading ctype was a mistake, as aborting and then attempting to load ctype again succeeds without having loaded pairwise.lisp
4:12:39
hayley
I don't know how that happens, but I suppose an instruction can be its own predecessor in valid IR, and it would be wise to not go into an infinite loop.
4:20:44
hayley
Hm, that case should be handled because the new pool will be pool<= to the old eventually, no? So that would not be the problem.
4:22:01
beach
I take your word for it. It is not fresh in my head, and I just barely finished my morning coffee.
4:22:59
beach
I am not sure it's correct that this situation happens here, but that's a different story.
4:28:49
hayley
Something is wrong with the output pools computed. A lexical location called function546831 has two entries in the pools that EDU computation gets stuck on.
4:33:24
beach
It is entirely possible that there is a problem in the EDU computation that causes this duplication.
4:47:05
hayley
I wrote a function that checks if a pool contains duplicate items, and it found some other occurrence of a duplicate item during bootstrapping.
4:48:08
hayley
In this case, the values are the same, so POOL<= would work correctly, but in the problematic case, the values were different and so POOL<= would presumably always return NIL.
4:48:19
beach
I see. Well, if you like, I can investigate that during the day, since I wrote that code.
4:51:54
hayley
Of course the function I am looking for tail-called CHECK-POOL-VALIDITY (which I just wrote), but I am suspecting POOL-MEET somehow.
5:33:36
hayley
The problem is actually in the default method for COMPUTE-NEW-INPUT-POOL. If one location is used as multiple inputs, multiple items are added for the location.
5:43:04
hayley
Should I keep calls to CHECK-POOL-VALIDITY in the finished code? My quickly written implementation calls REMOVE-DUPLICATES and it doesn't seem to be awfully slow. Bootstrapping still takes 43 seconds or so here.
5:49:02
beach
I'm at 51 seconds, but my new computer is a bit slower than the previous one. It is also dirt cheap compared to the previous one of course. And it doesn't crash. :)
5:54:36
beach
And MAP is one of the sequence functions, which suggests that I should load the sequence functions first. But then I have a host of other prerequisites to consider. Plus, I kind of decided not to use the version of the sequence functions that requires the FAST-GENERIC-FUNCTIONS library. Oh, well.
5:58:12
beach
I could break this dependency cycle as Bike suggested, by handling common special cases in SUBTYPEP before calling the ctype function.
5:58:45
beach
Like most code calling MAP or creating an array would probably mention the upgraded type directly.
6:03:25
beach
So now I wonder whether it is possible to avoid the use of SUBTYPEP in order to determine whether we have a "recognizable subtype of list/vector" without calling it.