freenode/#clasp - IRC Chatlog
Search
19:21:36
drmeister
Do you recall how to get the owner of an instruction - the enter instruction some other instruction belongs to?
19:22:40
drmeister
I've got an instruction in translate-simple-instruction - I need to know the owner of it.
19:27:28
drmeister
The problem that I wrestled with the last week is exception handling and CALL vs INVOKE for calling functions.
19:28:28
drmeister
So right now if a function can be the target of an UNWIND instruction, that function gets set up differently than a function that is not the target of an UNWIND instruction.
19:29:29
drmeister
Functions that are targets of UNWIND have any CALL to a function that can unwind the stack converted to an INVOKE.
19:30:24
Bike
what if there's an intermediate? like you have functions f1 f2 f3, f1 calls f2 and f2 calls f3, and f3 unwinds into f1?
19:31:39
drmeister
The INVOKE invocations get a thing called a 'landing-pad' attached to them. The 'landing-pad' is a place in the function that checks the C++ exception (stack unwinding) that is coming in to see if this function is the target of that exception and if so - it dispatches into the function and if not it rethrows the exception for a function higher up.
19:32:21
drmeister
If there are intermediates f1 f2 f3 and f3 unwinds to f1 then f2 doesn't need INVOKE or landing-pads.
19:33:15
drmeister
This works because Common Lisp generated functions don't have any cleanup that they need to do when they exit.
19:33:38
drmeister
UNWIND-PROTECT is handled by a C++ function that you pass a protected function and a cleanup function.
19:36:08
drmeister
Lambda list handling code can signal errors - but if those errors lead to stack unwinding - they are not caught by the function within which the lambda list processing error occurred.
19:37:07
Bike
Um... guess not. It's not like you can install a handler for a &key misparse in the body of the function doing the parsing.
19:37:23
drmeister
My question is coming out of the blue - so it's ok if not. I'm not trying to put you on the spot. Just trying to check my thinking and say this aloud so I think about it.
19:38:40
drmeister
Currently the HIR/MIR don't contain anything that represents the lambda list processing code. It's generated as llvm-ir when the enter-instruction is translated.
19:39:54
drmeister
Now, functions are called directly. I can't use DWARF because DWARF is too hard for me to tackle right now.
19:40:45
drmeister
So I'm going back to my approach of pushing a InvocationHistoryFrame onto the stack when a function that is compiled with DEBUG=3 on is entered and popping it from the stack when the function is exited.
19:41:13
drmeister
This means cleanup information needs to be installed for functions that have DEBUG=3.
19:42:33
drmeister
(1) I could install an outer landing-pad to cleanup and pop the InvocationHistoryFrame when the function is exited or when the stack is unwound through the function.
19:43:35
drmeister
(2) I could create a separate function that pushes the InvocationHistoryFrame and passes the arguments as a list to an inner function that works like I described above.
19:44:11
Bike
can you not just have the function itself pop the frame right before it unwinds or returns?
19:44:55
drmeister
The outer function spills allocates space on the stack for the InvocationHistoryFrame, spills register arguments into that space, and then passes the arguments as a list to an inner function that does what the function is supposed to do, returns and then the outer function pops the InvocationHistoryFrame.
19:45:49
drmeister
I could have the function itself pop the frame right before it unwinds or returns - but that gets a little complicated. The outer landing pad has to work with the inner landing pad that may or may not be there depending if the function was the target of an UNWIND.
19:46:38
drmeister
Also, if the function is not the target of an UNWIND and the function is a debug function, then all of the calls have to be converted to INVOKE's anyway.
19:47:43
drmeister
I'm wrestling with this right now. I don't want to complicate the current design too much.
19:48:31
Bike
i don't think i understand why they have to coordinate... however, looking at translate it should be easy to pass the owner to translate-whatever-instruction methods.
19:48:44
drmeister
Using two functions is something I just came up with just before I started talking about this.
19:50:13
drmeister
If I use two functions - it doesn't need to add overhead because LTO will convert the call to a fast-call or inline.
20:15:32
drmeister
I think I'll use two functions - that way I don't need to grossly change the way things work now.
21:51:19
Shinmera
drmeister: By the way, have you ever measured how much time of a build is spent in LLVM itself compiling things?
21:52:07
drmeister
Very little time is spent in llvm. The TIME macro reports on time spent in LLVM - although I noticed it was zero recently - maybe broken.
22:08:41
drmeister
If I do things outside of hir - keeping it in separate functions is better than mixing it in with functions that use hir