freenode/#clasp - IRC Chatlog
Search
16:56:11
Bike
there seem to be a few dozen call history entries that ought to end up using a method function but don't, and i'm not sure why
16:56:33
Bike
some of them are clos stuff, which is bad but probably just due to some bootstrap shit, but some in quicklisp also
17:01:31
drmeister
Hmmm - do they have anything else special about them? Are they fixed up in fixup.lsp?
17:40:02
Bike
the C++ faq spends quite a lot of time trying to convince the reader that exception handling is better than fucking return codes
17:40:41
Bike
and also doesn't seem to say anything about this issue, so i guess it's not a question frequently asked
17:44:02
Kevslinger
If you slide the first E to the end, you get NO MEMO, which would be the opposite of printf working
17:45:13
drmeister
I really hope that I can implement unwind-protect with C++ exceptions/itanium exception handling. I'm going to be really, really pissed if I can't.
17:45:52
Bike
it does mention "The C++ rule is that you must never throw an exception from a destructor that is being called during the “stack unwinding” process of another exception"
17:46:40
Bike
it might be a more general rule that you can't throw an exception during stack unwinding
17:47:28
Bike
you need to be able to say, okay i'm done unwinding with that exception, instead i'm going to unwind with this other one
17:49:22
drmeister
Well, C++ try/catch/RAII are implemented with itanium exception handling - I might not be able to do it with C++ - but I might be able to finess it with llvm and itanium exception handling if I implement it in llvm-ir.
17:49:42
Bike
like, if you have try ... catch (...) { whatever; throw; } then surely that halts stack unwinding during the catch block
17:52:23
Bike
as i recall, you moved away from it because it didn't seem to be working, perhaps due to some mismatch of manually used itanium exception handling internal calls
17:53:39
drmeister
I have to look at the try {protected();} catch (...) {cleanup(); throw} case and the LLVM-IR that it generates carefully to figure that out.
17:54:17
drmeister
Wait - it goes try {protected();} catch (...) {cleanup(); throw;} cleanup(); case
17:55:44
drmeister
Right now I'm looking at RAII again with the question "how would I fix this so that if the protected form throws an exception and the cleanup form throws an exception - how would I make it work".
17:55:58
Bike
by the way, did you know that the C++ faq says to not use bare pointers in constructors ever due to some confusing fact about exceptions? what is with this language.
17:57:21
drmeister
Not if I use RAII in C++ - but I could write a FUNWIND-PROTECT that would work in raw llvm-ir.
17:58:44
drmeister
RAII generates llvm-ir that handles every case except if both the protected form and cleanup form throw an exception.
18:01:17
Bike
in ir all we want to do is uh, "invoke protected() normally goto 1 otherwise goto 2; 1: cleanup(); 2: landingpad whatever; cleanup(); resume;"
18:08:28
drmeister
https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,options:(colouriseAsm:'0',compileOnChange:'0'),source:'%23include+%3Cstdio.h%3E%0A%0Along+__attribute__((noinline))+f(long+*l,+double+*d)+%7B%0A++*l+%3D+20%3B%0A++*d+%3D+0.0%3B%0A++return+*l%3B%0A%7D%0A%0Aunion+U+%7B%0A++long+l%3B%0A++double+d%3B%0A%7D%3B%0A%0Aint+main()+%7B%0A++union+U+u%3B%0A++printf(%22%25ld%22,+f(%26u.l,+%26u.d))%3B%0A%7D%0A'),l:'5',n:'1'
18:08:28
drmeister
,o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:clang390,filters:(b:'0',commentOnly:'0',directives:'0',intel:'0'),options:'-S+-emit-llvm+-fno-omit-frame-pointer'),l:'5',n:'0',o:'%231+with+x86-64+clang+3.9.0',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4
18:09:16
drmeister
If I lie to the C++ compiler and say that the cleanup destructor will not throw an exception - then we get llvm-ir that looks like what we want.
18:10:49
drmeister
ACTION did not expect that his entire life work hinged on implementing unwind-protect in llvm-ir.
18:11:46
drmeister
The morality of lying to clang? Or that just calling the Cleanup destructor would work.
19:31:23
drmeister
So the problem is probably that I'm not cleaning up properly when I throw and catch exceptions in cleanup-blocks.
19:41:23
drmeister
It looks more like it's behaving differently when run from within the test macro.
19:47:14
drmeister
Ok - all is well. bclasp fails the caught exception in a cleanup form cclasp works.
19:48:05
drmeister
Yes, it means what we suspected - there is still a problem with caught exceptions in bclasp - but funwind_protect is now working as it should.
19:55:52
Bike
sometimes methods aren't marked as leaves and i don't know why. if i run the defmethod again it fixes itself
20:06:00
drmeister
I'm guess that we are still spilling registers into the register save area of the generic function... checking...
20:07:26
Bike
by the way, to test the outcomes, just look at the call history. there's a fast-method-call structure
20:07:50
scymtym_
drmeister: you could also declare N to be of type fixnum to avoid generic arithmetic overhead. i have seen these things matter in my own fastgf benchmarks
20:23:04
Bike
well... beats me. they're functions that exist, i assume there's an llvm name for them somewhere
20:28:58
Bike
well, you can just turn on debug fastgf and get the thing dumped as ir i can actually sort of read
20:31:58
drmeister
Why is there double and float math in the loop? Is that the inlining without type inference and elision?
21:22:26
drmeister
It's calling llvm.va_end on an uninitialized va_list in dispatch-va_list* - that's not good.
21:28:22
Bike
i found a bug in applicable-method-p, not sure if it's what's causing the weirdness though
21:28:32
drmeister
We could get rid of some of the bit shifting if we compared the stamp to tagged stamp values - but other than that - I don't see much more room for improvement.
21:29:43
Bike
applicable-method-p thinks that a call history entry with an eql specializer never has any methods without eql specializers in that position apply to it, which is pretty wrong
21:31:02
drmeister
generic functions that take eql specializers and class specializers in the same position - I'm puzzled by some aspects of that.
21:31:25
drmeister
What if you have (defmethod foo ((x (eql 'a))) ...) (defmethod foo ((x symbol)) ...)
21:32:34
drmeister
I didn't know that eql specializers mean "more specific" if the eql specializer applies.
21:33:17
drmeister
But you are saying that if the eql specialized method calls call-next-method - it should end up in the symbol class specialized method.
21:35:36
Bike
i ran into this with cleavir-compilation-policy:compute-policy-quality, which is in this situation of having an around method
21:36:15
Bike
and... it not being called actually explains some weird behavior i noticed months ago, but isn't anything major
21:44:48
drmeister
Understood - I only say that because it involves code walking and the code walkers (bclasp and cclasp) are a little squirrelly.
21:48:39
drmeister
We inherited this generic-function slot called spec-list - it keeps track of when a generic function argument position includes eql specializers or not - I only have a vague idea of how it works.