freenode/#clasp - IRC Chatlog
Search
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.
3:00:22
Bike
minion: memo for beach: there are instructions for converstions between float types but no primops/asts; i was going to add them with two types so you'd write like (cleavir-primop:coerce single-float double-float x). also, there's one for "unboxed integers", does this mean fixnums with tag shifted out to take advantage of machine instructions?