freenode/#clasp - IRC Chatlog
Search
14:21:05
drmeister
I discovered that my dispatch functions drop one call history entry under some yet unknown circumstances
14:21:37
Shinmera
That sounds like it might be a bad push somewhere, or forgetting to increase the fill-pointer.
14:39:56
drmeister
There's no concurrency - and yeah - it's a corner case somewhere. It has an optimization step that coalesces ranges of stamps. I'm turning off fastgf and rebuilding so that I can experiment with the dispatcher compilation
14:40:10
scymtym
drmeister: i had a decision tree generator (from working on a pattern matcher/parser) and wrote my own code using that
14:42:33
drmeister
The method requires that objects contain unique integer stamp values and that classes write this stamp into newly allocated objects.
14:43:08
scymtym
instance objects reference layout objects. i use the layout object as whole as a replacement for the stamp
14:43:57
scymtym
the immobile-space variant of sbcl keeps layouts at fixed address, so the respective layout address can be that integer
14:45:18
drmeister
So - instances point to their layout object? You can identify obsolete instances in that the layout object they point to is different from the layout object for their class?
14:46:34
scymtym
i haven't tried that, but i think i would remove obsolete layouts from call histories so that the corresponding instances get trapped
14:51:03
scymtym
btw, an initial version of the code is at https://github.com/scymtym/dispatch-experiment . since then if have added and not yet pushed dispatch on "lowtags" and "widetags"
15:00:44
drmeister
I'd need more context - the only reason I can see that it can't parse bitcode is if somehow you used the system clang when it should have used the externals-clasp one.
15:02:10
drmeister
Bitcode with errors often can't be read by anything - they aren't fault tolerant at all.
15:02:38
drmeister
At that point I set things up to write the .ll files for the module as they are generated - that's a bit involved
15:03:08
drmeister
Ok, then there is bad llvm-ir in there and we need to generate the .ll file instead of the bitcode to figure out what it is.
15:06:06
Bike
so, i could have generated bad code that still passes whatever and is output to a file, but then the loader refuses it?
15:07:10
drmeister
I've run into this several times. The only way I've found out is to write .ll files. We can read those and run them through llc and opt on the command line.
15:34:42
robink
ebuild pull request ('dev-ebuild' branch of https://github.com/Haifen/clasp, single commit) submitted.
15:51:44
robink
drmeister: Once 'dev' builds cleanly I'll submit an ebuild bug (with the last-known-working ebuild attached) to bugs.gentoo.org.
16:48:20
drmeister
::notify Kevslinger Tomorrow (Sep 15) The Cassyny probe is going to crash into Satyrn after thyrtyyn years in spyce.
17:04:03
Bike
slime compilation wrote out a temporary .bc, and said it wrote a temporary .fasl, but it's not actually in the system
17:20:33
Bike
the problem is the bit aset, but it works in the repl. i don't know what's going wrong.
17:37:32
Bike
i mean, i don't know how. the disassemble output looks okay, insofar as i can understand it. i think the array access actually ended up properly as a gep
17:40:27
drmeister
So you would like to write out .ll files instead of .bc during the build process?
17:41:28
Bike
unless you have a better idea. i don't know what's happening beyond fasls not being produced.
17:41:50
Bike
which i'm guessing is due to something seeing that it can't read bitcode and going "oh, well, better just return normally as if i really did write out a fasl then"
17:43:16
Bike
it's a perfectly good clasp, except if you use this one primop in the wrong way this happens
17:44:35
drmeister
Try this - bind cmp:*compile-file-debug-dump-module* to T around the COMPILE-FILE
17:47:34
Bike
well, wait. now i don't know what's happening. if i move the errant definition to a file it compiles and loads! but with C-c C-c in a buffer it gives the error
17:49:05
drmeister
I don't know - I'd like to look at an .ll file that is generated in place of the .bc file that is bad.
17:50:50
drmeister
What that variable (or a slightly different debugging setup) is supposed to do is write out .ll files for intermediate stages of the build. Incomplete modules can be written out just fine.
17:51:33
drmeister
Or run 'opt' or 'llc' on them. They usually point out the problem if there is one.
17:54:02
Bike
"; Function Attrs: nounwind" "declare void @cc_simpleBitVectorAset({}*, i64, i32) local_unnamed_addr #1" seems okay
17:56:36
Bike
as does "%aset = call void @cc_simpleBitVectorAset({}* %farg0, i64 %untagged-offset, i32 %untagged-value)"
19:28:36
drmeister
My problem appears to be when a class is redefined the generic functions that have specializers in entries in their call history are not getting those entries cleaned out - they should be. They are cleaned out in small test cases.
20:06:34
Bike
inling float arithmetic seems to speed it up three times or so, even before box elimination
20:08:12
Bike
i guess i'll implement some more instructions/etc for coercing fixnums to floats and such
20:09:46
drmeister
ACTION has been itching to break that stuff up into little functions that can be inlined.