freenode/#clasp - IRC Chatlog
Search
14:37:31
Bike
i read it wrong, caller and callee only need the same prototype for musttail, not tail. still need the same calling convention though. that's annoying.
15:18:37
drmeister
You can look in build/boehm/generated/enum_inc.h for what is being exposed via clbind.
15:20:49
drmeister
I thought the translators would be generated by the macros as well - but that doesn't appear to be the case.
15:22:22
drmeister
The translators need to be available where the call is exposed so that the template code knows what to do.
15:25:18
drmeister
So SOMEWHERE there needs to be a to_object and from_object translator for llvmo::ClaspCallingConv. I'm starting to think we have to write it ourselves. Looking...
15:28:09
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L114
15:31:31
drmeister
I think all header files get included before the scraper generated code that exposes functions gets compiled - so the code generated by the ENUM_TRANSLATOR will be available for the clbind template code.
15:38:57
drmeister
Clasp has built with compile-file-parallel 12 times since I changed SharedMutex and turned it back on. I'm ready to declare that the weird crashes to be due to the old broken SharedMutex.
15:42:25
Bike
i didn't do an ENUM_TRANSLATOR when i defined the atomic ordering enum, and that works fine
15:48:24
Bike
tons of compile errors. "error: no template named 'to_object': did you mean '::translate::to_object'?"
15:52:04
drmeister
Ihttps://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L114
15:52:07
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L114
15:53:11
drmeister
It's not dicey - it's just stupid. If you put ENUM_TRANSLATOR inside of namespace llvmo then you end up in llvmo::translate::from_object - that can't work.
15:53:55
Bike
well no, i mean the dicey part is i don't understand why this enum needs ENUM_TRANSLATOR and others don't.
15:54:38
drmeister
It's probably why I don't use it much - C++ macros with bizarro rules about where you are allowed to use them suck.
15:55:11
drmeister
I don't know. What is the name of a function that takes one of these other enums?
15:59:50
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/llvmo/llvmoExpose.h#L4527
16:02:42
drmeister
When the code that exposes the function that takes or returns these enumerated types is compiled clang needs to have the template specializer for to_object and from_object available - otherwise it falls back to the default and the default cant do anything useful with it and you get those alien whatchamawhosits errors.
16:04:49
drmeister
The macro is in the .cc file? I don't think that will work. This is arcana - but IIRC these functions all get exposed inside of gc_interface.cc and that source file includes every header file - so those translators need to be in the header file.
16:06:39
drmeister
The downside of having them in header files is if you change them - then you need to recompile EVERYTHING.
16:07:09
drmeister
So I tend to now put SYMBOL_EXPORT_SC_ and CL_ENUM_xxx in .cc files and the translators go into header files.
16:09:07
drmeister
Try the header file, right after the enum is defined, in the top level namespace.
16:10:47
drmeister
If you really want to see the sausage being made - run the C preprocessor on gc_interface.cc - that shows everything to do with exposing functions.
16:11:52
drmeister
Any .def("xxx",&xxx) where xxx takes some weird enum will be preceded by the translator and that will be preceded by the enum definition. You will have to wade through a million lines of code.
16:15:48
drmeister
We have a bit more fussiness because the scraper generates code and it gets included in gc_interface.cc and these translators need to be available when gc_interface.cc is compiled - so I generally put them in header files.
16:18:06
drmeister
Yeah - there isn't a single translator in any .cc files in clasp except for astExpose.cc and clangTooling.cc - and they use the public clbind.
16:18:58
drmeister
This stuff is very opaque as well. It's C++ compile time type/template resolution.
16:40:56
Bike
it built except that it crashed for unclear reasons while building asdf. so imma try it again
17:55:54
Bike
also, right now llvm-sys:set-calling-conv does a kind of manual dispatch rather than using a single dispatch gf, which kinda sucks?
19:10:01
drmeister
Bike: Agreed on the manual dispatch - although single dispatch may suck more. What we really need to do is make single dispatch use the generic function dispatch machinery.
19:10:24
drmeister
We were able to do this for a while - because we have the generic function dispatch interpreters.
19:12:14
drmeister
Can you remind me again why we wrote this wrapper? Kerrrriisst - I'm like a gold fish - moving from one problem to the next and immediately forgetting the solution or reason for the previous problem.
19:13:01
drmeister
This was one of those situations where I said I felt compelled to write a wrapper - or that we had to write a wrapper.
19:17:02
Bike
which is why i'll need to do something similar for setAtomic even though the enum type is not anonymous
19:22:07
Bike
void llvm_sys__ste_calling_conv(T_sp obj, ClaspCallingConv conv) { if (gc::IsA<CallBase_sp>(obj)) { gc::As_unsafe<CallBase_sp>(obj)->wrappedPtr()->setCallingConv(conv); ...
19:23:51
drmeister
And this won't work because the setCallingConf takes a llvm::CallingConv::ID, which is a typedef for uint8_t - right?
19:24:27
Bike
right. i mean, it "works" in the sense that you can then pass it a number instead of an enum symbol
19:26:49
drmeister
CL_EXTERN_DEFMETHOD(CallBase_O, (void (*)(llvmo::ClaspCallingConv))&CallBase_O::ExternalType::setCallingConv);
19:27:24
drmeister
I'm not sure it will work. I've used these method pointer casts to select overloaded methods.
19:28:31
drmeister
Here I'm trying to convince the compiler to cast the function pointer to one that takes a ClaspCallingConv as the argument. The argument doesn't need to be converted because your enums have the same integer values as the original llvm::CallingConv::ID values - right?
19:29:39
Bike
will it work with getCallingConv too, do you think? so only the return type is different
19:32:01
drmeister
In C++ you aren't allowed to overload function/method names that only differ in their return type. That touches on this but it shouldn't cause us any problems. We are casting one function pointer into another function pointer with a type that the compiler can use to find an appropriate translator. The llvm::CallingConv::ID and llvmo::ClaspCallingConv are bitwise identical.
19:42:37
Bike
we're not casting it to a void*, are we? we're casting it to another function pointer, so it's fine
20:22:40
Bike
and was talking about the possibility of another entry point to handle varargs but didn't take a closure
20:23:13
karlosz
https://github.com/clasp-developers/clasp/commit/370c82f80f6000350c132f0aa6feda0122a8b06a
20:24:04
karlosz
that way we never need to cons closure vectors for any type of local call no matter the lambda list
20:31:15
karlosz
so i implemented if-if elimination the other day and noticed for (If (not x) ... ...) the fact that we get f->m and m->f pairs sort of blocked the optimization
20:31:48
karlosz
its not that delete-transmission doesn't work anymore, its just that when the metaevaluator is simplifiying the flow graph those pairs can come into existence
20:32:37
karlosz
then the metaevaluator simplifies the flow graph and you get those next to each other
20:33:15
karlosz
so i was thinking by pushing f->m and m->f coercion instructions later we wouldn't have to worry about having to eliminate pairs of those instructions all the time
20:33:59
karlosz
unlike with constant reference it doesn't seem like an high level optimizations will ever take advantage of the fact that those instructions are "there"