freenode/#clasp - IRC Chatlog
Search
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
21:04:25
Bike
ok, actually, thought: we can make all calls local regardless of their lambda list, we just can't inline them or use the "main" function rather than the xep
21:30:11
Bike
well here's the thing. Say cleavir just blindly made everything a local call based only on whether the function is in the module. Couldn't the client then handle that?
21:30:26
Bike
I'm thinking about this because i'm wondering if all clients will be able to handle all lambda lists
21:42:26
Bike
i suppose i'm basically separating that out, so that the local call analysis only analyzes one thing, whether the function being called is in the module
21:42:46
Bike
that's a pretty straightforward thing to do, unlike lowering calls or deciding what to do with a bad call, i think
21:43:15
Bike
at the moment i'll move it into maybe-interpolate in such a way that it should pretty much happen at the same time anyway
21:45:51
no-defun-allowed
I thought I had found some code to rebuild the table, but after building cboehm I couldn't find the build_commands.json file that it needed.
21:46:17
drmeister
no-defun-allowed: I just got through rebuilding the table - testing the build_cmps build now.
21:46:51
drmeister
FYI: You can do this on linux - but there are problems running it on macOS because they use a different version of the C++ std library.
21:48:15
drmeister
You can break it up - but the build_impsprep needs to be run from a clean build because it builds a database of all of the C++ code that analyze_clasp uses. If you interrupt the build_impsprep and then start it up again - you only get a partial database and all heck breaks loose.
21:48:57
drmeister
If you are running this in clasp you get a src/main/clasp_gc.cc file that is ready to go. You can run ./waf build_cmps right away.
21:49:04
Bike
uhh. wait, i can't use closure-call-or-invoke since there's no actual closure. okay, so this isn't completely trivial..
21:49:34
drmeister
If you are running this with cando it will build a src/main/clasp_cando_gc.cc file (I think that's what it's called). It's bad form that we dump a cando file in the clasp tree - but I haven't had time to clean this up.
21:50:11
no-defun-allowed
I vaguely recall there being an error related to the values used as EQ hashes (and I forgot the name) that would prevent cmps from compiling; the setter tries to return a value when setting with AWL and it casts the LHS which G++ doesn't like without AWL.
21:50:59
no-defun-allowed
But then I replaced my clasp/ directory with a new one in the end, so it might be leftover from something.
21:57:27
Bike
shoudl shelve this for a bit i think. thought it would be easier than mv-local-call but they'll both have this issue
21:57:47
Bike
having another entry point wouldn't be a win really, since it would take varargs and thus not be tail callable
22:17:22
Bike
but no, i suppose this entry point could be simpler, since the number of arguments is known (for calls, not mv-calls)
22:19:21
drmeister
no-defun-allowed: Right now I'd like to reevaluate problems in light of the new SharedMutex implementation. SharedMutex was broken - and now it should work. Maybe some of the weird bugs that occasionally popped up were due to that.
22:21:35
drmeister
This new SharedMutex might be useful for MPS. I believe MPS suffers in its multithreaded performance because of false sharing.
22:22:14
drmeister
I should run some tests comparing our old SharedMutex (after fixing it) and the new SharedMutex.
22:23:46
Bike
so i could probably do this but it would mean returning to cmp/arguments.lsp, and i don't wanna
22:34:25
drmeister
Note: This is for clasp - not for cando - I'll start the static analyzer for that now.
23:19:23
karlosz
Bike: it would be nice if we could make calls to &key with constant keys local calls but that would entail messing with cmp/arguments.lsp a lot right?
23:20:07
karlosz
also it would be nice if we could have a lighter weight entry point mechanism, cause a full llvm function with a full description and everything tail calling in is still some amount of overhead
23:20:56
karlosz
er, i take back "messing with cmp/arguments.lsp". it would just mean we need to parse lambda lists harder :/