freenode/#clasp - IRC Chatlog
Search
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.
20:45:27
Bike
hm i need to ask beach about some instructions in cleavir he probably hasn't had occasion to think about for years
20:51:46
Bike
drmeister: if i want to export symbols from CORE, how should i go about that? i've already added, like, five special operators in the course of this array shit
20:53:12
drmeister
Lower down I initialize their values where you see all the _sym_foo->defparameter(...);
20:57:12
Bike
it's not high priority or anything. just means i have (core::%displacement ...) and stuff around
20:57:20
drmeister
If they are special operators then there is stuff like special-operator-p that needs to know about them.
20:57:46
drmeister
Since I'd like to smarten up the aclasp and bclasp compiler - I think it behooves us to put them in the corePackage.cc file.
0:41:39
drmeister
This way that I use to identify all generic functions that may need their call-history edited when a class changes...
0:41:40
drmeister
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/closfastgf.lsp#L453
0:42:04
drmeister
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/closfastgf.lsp#L450
0:44:43
drmeister
The call-history entry of INITIALIZE-INSTANCE that specializes on PRETTY-STREAM and every subclass of PRETTY-STREAM needs to be removed from INITIALIZE-INSTANCE's call history.
0:45:17
drmeister
I thought that code would provide a list of generic functions that needed to be edited like this - but it doesn't.
0:46:20
drmeister
It will miss INITIALIZE-INSTANCE because INITIALIZE-INSTANCE only has a method on T and not PRETTY-STREAM or any subclass.
0:51:38
Bike
wait, but if it only has a method on T then redefining pretty-stream doesn't matter to it.
0:58:41
drmeister
I need to remove the INITIALIZE-INSTANCE call-history entry for any previous calls where a PRETTY-STREAM was passed to INITIALIZE-INSTANCE because ...
1:00:13
drmeister
It's not a bad idea because it will generate a dispatch-miss the next time and be added back.
1:01:21
drmeister
Right - because redefining the class means that probably the effective-method-function for INITIALIZE-INSTANCE when passed a PRETTY-STREAM should be re-evaluated.
1:02:04
drmeister
Right, it contains a history of all actual specializers (and satiated ones) passed to the generic function.
1:03:19
drmeister
I could check all generic-functions and edit their history. But I'm trying to do this more efficiently and get the subset of generic-functions that may need to be updated and avoid the ones that absolutely won't need to be updated.
1:18:17
Bike
well, actually, wait. when you redefine a class, the new class will have a new stamp, and all instances with the old stamp will be obsolete, right?
1:19:53
drmeister
INITIALIZE-INSTANCE has a call history entry with the selector for PRETTY-STREAM with stamp 851
1:21:29
drmeister
The dispatch function for INITIALIZE-INSTANCE isn't updated because it isn't included in the list of generic functions that were updated when the change class happened
1:21:52
drmeister
Then INITIALIZE-INSTANCE with a fresh instance of PRETTY-STREAM, with the stamp 2021
1:22:23
drmeister
The dispatch function triggers a dispatch-miss because it's expecting 851 - it doesn't know anything about stamp 2021
1:23:31
drmeister
The dispatch-miss generates a new effective-method-function and calls the function that updates the call history but that immediately returns because the call history still contains an entry with the selector for PRETTY-STREAM -
1:24:40
drmeister
The last part? "The dispatch-miss generates a new effective-method-function and calls the function that updates the call history but that immediately returns because the call history still contains an entry with the selector for PRETTY-STREAM - "
1:25:43
drmeister
No - the call history is classes (specializers, specializers - I started saying selectors again) and eql-specializers
1:25:59
drmeister
I have this function for updating a call history: clos__generic_function_call_history_push_new
1:26:23
Bike
it seems like that's conceptually the problem then - the dispatcher and the call history are tracking different things.
1:26:31
drmeister
It returns false if a new entry isn't created in the call history. I won't create an entry if there is already an entry with the same selectors.
1:27:35
drmeister
Well, yes, that's why I invalidate these generic-function dispatch functions when I redefine a class.
1:27:57
drmeister
The call history is definitely selectors keys and effective-method-function values.
1:29:04
drmeister
You invalidate the generic-function with dispatch functions any time the call history and the dispatcher might get out of date - like when you redefine a class.
1:30:10
drmeister
I haven't thought it through - but beach was very clear on that point. It's specializers. So I never gamed it out.
1:31:14
drmeister
I imagine update of the call-history would be tricker. If you redefine a class you have to remove call history entries that contain the old stamp and add ones that have the new stamp...
1:32:30
drmeister
I don't think it would change my current problem - which is to identify the subset of generic functions that may have their call-histories edited because of a redefined class and that will have to be invalidated because of a redefined class.
1:32:57
Bike
i mean, you could just leave the old stamp around, and the invalidated dispatcher would probably compute the new call history entry, i figured.
1:34:00
drmeister
No - that's not how I understand things to work. An invalidated dispatcher does nothing but compile the call history into the new dispatcher - while completely avoiding generic function calls.
1:36:08
drmeister
The call history is the history of all previous memoized calls - the specializer for a particular argument for a memoized call is the class - the stamp of the class might be used - but I haven't thought it through.
1:38:01
Bike
i meant that i don't know what computes call history entries, and what does so wasn't really my point
1:38:32
drmeister
Mind you, I'm not arguing - I'm just trying to hold on to what I think I understand to sort out what I think is my problem.
1:39:30
drmeister
You compute call history entries on a dispatch-miss. It constructs a key and evaluates the effective-method-function and adds those to the call-history.
1:43:09
drmeister
I'm pretty sure my problem is I'm not invalidating the dispatch function of the INITIALIZE-INSTANCE generic function when PRETTY-STREAM (which it has a call-history entry for) is redefined and the INITIALIZE-INSTANCE dispatcher tests for the old stamp.