freenode/#clasp - IRC Chatlog
Search
19:36:55
Colleen
frgo: drmeister said at 2017.05.18 15:57:33: The new way functions are calling each other may require some adjustments to defcallback.
19:40:14
frgo
While you both wrestled with git I enjoyed a QSO (a talk over radio) with Guadeloupe - some 8000 km away from Germany using my ham radio gear - there being nice weather while we have cold rainy weather here.
19:54:56
Bike
that commit changes how cell creation works, but i don't think i can even guess what the problem is without knowing where it's braking
19:56:12
drmeister
It should have been writing to a CONS cell but the tag on the object being written to was that of a tagged VaList_S* pointer - but a memory location that indicated it was on the heap and not the stack.
19:57:13
drmeister
I'll bring it up in the debugger and show you what I've got - it's sketchy because of the lack of debugging info higher up.
21:20:02
drmeister
The last nibble 0xd is #b1101 #b101 is the tag for a VaList_S* tagged pointer. That should have an address like 0x7ffff... on the stack.
21:20:21
Bike
well, what that commit does is move create-cell instructions later in functions (previously they were all concentrated at the entry point)
21:20:38
drmeister
But Common Lisp code shouldn't cause low level problems like this. It's clearly a problem in Clasp - interacting with something weird in the CL.
21:21:22
Bike
so if you have like (loop for i below 5 collect (let ((x i)) (lambda () x))) it'll create cells in the loop.
21:23:18
Bike
it's possible i did something wrong so that a variable that's supposed to hold a cell is never initialized, or something.
21:29:51
drmeister
What if it's moved the cc_makeCell to later but left the cc_writeCell in the entry block? It would be writing to unintialized memory.
21:31:26
drmeister
The cc_makeCell is called, it allocates a CONS cell on the heap and returns it to be stored in the instructions output.
21:32:09
drmeister
But I'm not sure what ensures that the write to a cell has to happen after the allocation of the cell.
21:32:55
Bike
https://github.com/Bike/SICL/blob/master/Code/Cleavir/HIR-transformations/compute-ownership.lisp#L66-L89 this
21:40:04
drmeister
Another data point - if I start the compilation again mislib.lisp compiles fine and it crashes later on.
21:41:10
drmeister
But that should be bclasp generated code - which doesn't use cc_writeCell or cc_makeCell
21:54:27
drmeister
I'll put in a trap that will signal an error if a cc_writeCell gets a non cons cell.
21:56:36
drmeister
The CL backtrace doesn't make sense on second look. The convert-form is bclasp generated code and does not use cc_writeCell.
21:57:44
drmeister
This (http://llvm.org/docs/DebuggingJITedCode.html) and suggestions from #llvm have never worked for me.
1:37:50
drmeister
There are untagged pointers higher in the stack trace that I'm putting in tests/traps for.
2:02:52
drmeister
Bike: What do you think about a 'lint' for HIR/MIR? Something that checks to see if it's well formed?
2:04:42
drmeister
I'm suspecting that a writeCell is being invoked before a makeCell - but I'm not sure.
2:04:49
Bike
if you mean for stuff like "a cell is created before it's used" that's a little hard to check
2:12:00
drmeister
The stack above that call is weird - there are bad tagged pointers for function calls.
2:17:13
drmeister
I'm going to have the undergrads who are working on the UI stuff work with a development system running in docker.
3:14:30
Bike
new kildall works with the type inference, which has reminded me again that i need to fix ast-to-hir or something, because the proliferation of temps is absurd even if llvm will kill them later
3:57:04
Bike
it means i changed how kildall works, and then changed how the type inference built on kildall works to match it.
4:04:19
drmeister
I'll have to leave this new problem with code generation until next week - I have to focus on yet another grant proposal.
4:08:28
drmeister
You say when they begin and end their lifetime. It should be easy to generate that information.
4:09:49
Bike
yeah. but after segregate lexicals. because what "lifetime" means when a variable is in multiple functions isn't as obvious.
4:10:27
drmeister
So you have lifetime for variables that are in one function. There is no concept of variables in multiple functions in llvm.
4:12:58
drmeister
Could it be preserved to code generation? Say in a way that we know for a particular instruction that a variable has just come alive and the instruction after which it is no longer alive?
4:13:33
Bike
clasp computes it here https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/cleavir/translate.lisp#L957 but it can be done any time after process-captured-variables.
4:15:17
Bike
it could be recomputed, yeah. i don't know what you want to use it for so i don't know what the consequences would be.
4:15:36
Bike
i've been thinking a bit about how to do hir transformations while preserving information like that more scrupulously, but i haven't done any work.
4:16:32
Bike
the liveness object is just a hash table (actually two) from instructions to lists of lexical locations live there, i don't know if that's convenient.
4:16:35
drmeister
Interesting: https://www.phoronix.com/scan.php?page=news_item&px=LLVM-EfficiencySanitizer
4:21:21
drmeister
I can't find it right now - but there is a web page that suggests basic things that compiler writers should incorporate when using llvm. Specifying liveness of lexical variables was one of them
4:30:48
drmeister
??? is a JITted Cleavir function calling a generic function Instance::entry_point with a C-calling convention call.
4:31:32
drmeister
standard_dispatch looks up the effective method and invokes apply_method, passing arguments in a VaList_S* tagged pointer (no arguments copied)
4:32:07
drmeister
apply_method invokes funcall_consume_valist_ which calls funcall_va_list_8 (arguments are copied)
4:33:02
drmeister
That involves invoking apply_method /funcall_consume_valist_, funcall_va_list_8 (arguments are copied)
4:34:13
drmeister
They need to be copied once because the arguments list and list of next methods get prepended to the arguments.
4:36:23
drmeister
In the common case where there is a single method one of those argument copies could be eliminated and COMBINE-METHOD-FUNCTIONS3.LAMBDA could be skipped.