freenode/#clasp - IRC Chatlog
Search
8:53:51
no-defun-allowed
"../../src/gctools/hardErrors.cc:46 Bad client pointer 0x7feca8f65990" Maybe not then.
9:47:08
no-defun-allowed
I figure the stamp numbers are addresses into the big table; so I tried to build cboehm to run the generation code, but that also appears to go wonky.
14:18:04
Bike
CallInst_O and InvokeInst_O both have CallBase_O as a super, and that's where most of the relevant stuff is
14:18:18
Bike
but instead of using the call base method in llvm they seem to be defined individually for call and invoke
14:18:56
Bike
when i tried moving e.g. the addParamAttr function from call and invoke to call base, i got... er... actually this might just be a const correctness thing, one sec
14:21:40
drmeister
So in llvm llvm::CallInst and llvm::InvokeInst both inherit from llvm::CallBase - and we mirror the class hierarchy in llvm.
14:38:44
drmeister
I find it a bit difficult to read diffs - you are on bigmac - right? I can mosey over to the files and look at them. This is in the clasp or cando directory?
14:41:10
Bike
clasp. i think it might have just been me missing a declaration though, it seems to be building now
14:41:39
Bike
so then i just need to put in an EXTERNAL_DEFMETHOD whatchamacallit for these. is it ok that Function_O and CallBase_O have unrelated methods of the same name? they should have the same signature
14:45:27
drmeister
What I had before was kind of a mess - I don't know why I did that. I should have done everything through CallBase.
14:45:55
drmeister
Yes, adding EXTERNAL_DEFMETHOD should let you expose the llvm function more directly without a wrapper.
14:46:16
drmeister
That being said - sometimes I have to do a wrapper for whatever reason. It's C++ right?
14:52:18
drmeister
The llvm setcallingConv and getCallingConv pass and return CallingConv::ID - do you have a translator for that?
14:55:43
drmeister
https://github.com/clasp-developers/clasp/blob/master/src/llvmo/llvmoExpose.cc#L616
14:57:35
drmeister
You define one symbol to store the translator object (here _sym_CodeGenFileType I think).
14:58:13
drmeister
Then you use CL_BEGIN_ENUM, CL_VALUE_ENUM and CL_END_ENUM to set up the translators.
14:59:06
drmeister
https://llvm.org/doxygen/classllvm_1_1Function.html#a5f494edc0a569c7fc9ff4181243be1ed
14:59:45
drmeister
Scroll up from here: https://llvm.org/doxygen/namespacellvm_1_1CallingConv.html#a188c0836f8c3528401f1c236fd93b977
15:08:45
drmeister
no-defun-allowed: I'm running the static analyzer for clasp now. You can't get around it. When we make certain changes to the clasp C++ we need to rerun the static analyzer to allow us to build MPS.
15:18:44
Bike
the enum is going to be annoying because it's anonymous and ID is just an alias for unsigned
15:19:36
drmeister
I don't think it will matter - although it may need some finessing - it just needs to map symbols to integers.
15:20:32
drmeister
Under the hood it uses this thing... https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L41
15:22:45
drmeister
I am hopeful that the broken SharedMutex was the cause of the problems with compile-file-parallel. I've turned compile-file-parallel on again and I'm rebuilding on the buildbot repeatedly.
15:25:34
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/cmp/cmpir.lsp#L702 and a few other places in this file
15:25:46
Bike
i added the enum for the atomic ordering itself fine, as you can see on the line above with monotonic
15:25:48
drmeister
https://github.com/clasp-developers/clasp/blob/master/src/llvmo/llvmoExpose.cc#L3400
15:26:53
Bike
so with CL_EXTERN_DEFMETHOD... i just put that in llvmoExpose.cc and not the header/class definition?
15:28:37
drmeister
The way the scraper works, in header files those declarations end up in lots of .sif files and if you make a change you have to rebuild everything. It's a headache.
15:29:07
drmeister
If we put them in .cc files then only one .sif file will contain the declaration.
15:29:27
drmeister
It's tangential to your question though - CL_EXTERN_DEFMETHOD work well in .cc files.
15:31:32
Bike
the other thing i want to work on is doing multiple-value-calls directly in some cases, rather than through the C++ functions. seems like that's gonna be involved, though
15:42:16
drmeister
Functions can return two values in registers with the C++ calling convention - are you going to do something else?
15:43:27
Bike
first off we do some weird thing with thunks for multiple-value-call with multiple argument forms
15:43:42
Bike
i think it does that trick where we allocate a C++ array and then it ends up being used as va_args via magic?
15:47:44
Bike
beyond that, i mean, if we have (m-v-c f (a)), then we can construct calls directly depending on how many values A returns
16:12:34
Bike
i guess as a transitional measure i could just define something like cc_call_multipleValueOneFormCallWithRet0 but taking a function pointer instead of a closure... maybe
16:15:48
Bike
except i'm just passing an 8 instead of an anonymous enum, so that would be good to figur eout.
16:18:05
Bike
i think the problem was that even if there is an enum translator defined, clasp won't use it since the underlying type is just unsigned instead of the enum type
16:18:52
Bike
...and i probably can't have a cc_call_multiple_etc analogue taking a function pointer, since there's an infinity of possible function types. drat.
17:42:01
Bike
given that the enum for calling conventions is actually anonymous, i don't think i can use it as a parameter. i guess i could like, define my own enum with coinciding values?
18:42:43
Bike
karlosz: i'm looking at doing an mv-local-call and stuff now, and i think i've lost the thread of what would be best for the kind of operations you want to do
18:43:24
Bike
karlosz: it seems to me that we'd want to interpolate mv-bind, more or less, but if we do we'd put in some multiple-to-fixed-like instruction. but you seemed like you didn't want that
18:43:45
Bike
and just leaving things as calls doesn't seem to change the situation much, you'd still essentially need to deal with the semantics of variable arguments/values
18:46:53
Bike
i mean, it's possible we could just not have MTF on basic stuff like wanting the primary value? is that the only problem?
19:56:34
karlosz
Bike: if we interpolate mv-bind, won;t there just be no values stuff at all? like just turning it into a LET? that's what i think when i think 'interpolating' mv-bind
19:56:34
Colleen
karlosz: drmeister said at 2020.11.21 15:20:01: Yes - there is a way to run what buildbot runs locally - check with me when you come on and I'll connect you to that.
19:56:34
Colleen
karlosz: drmeister said at 2020.11.21 18:14:42: I updated wscript to use the cleavir commit you suggested - that works now. Do you have any experience using LLVMContext::diagnose? I'm trying to link llvm modules together and I'm getting an error but I can't get the reason for the error. Frustrated.
19:56:34
Colleen
karlosz: drmeister said at 2020.11.21 18:45:03: There was no problem with my linking. The problem was I was working in pidgin Common Lisp (very early in the bootstrap process) and WHEN wasn't defined - so it evaluated the arguments of a nonexistent WHEN function and reported an error when it shouldn't have. I don't just work with Common Lisp and C++ - I need to work with a range of pidgin Common Lisp dialects.
19:57:39
Bike
which is, like, an important case, but wouldn't cover everything we're pseudo-interpolating now
19:58:41
Bike
i mean, right now multiple-value-bind never generates a separate function. if i switched it over to using mv-call but only interpolated when the number of values was known, we'd leave a lambda around much of the time.
20:01:09
Bike
at this point i'm not even sure how to compile down a local call rather than use a closure, but it's probably doable
20:02:11
karlosz
Bike: yes i think you're right about needing some kind of way to do multiple-to-fixed
20:02:53
karlosz
i was imagining we wouldn't have these 'coercion' instructions generated until later, like bmir or something
20:03:28
Bike
yeah, as far as boxing and unboxing goes i agree delaying it more than i was thinking is probably the way to go