libera/#clasp - IRC Chatlog
Search
13:07:49
drmeister
::notify kpoeck No reason - I think I just assumed that git would return 8 characters (2^3) - I don't see any reason we can't make it longer. I'll do that.
13:15:48
drmeister
::notify kpoeck Also, it takes the characters from the end of the git rev-parse HEAD result while git rev-parse --short HEAD returns the 9 characters from the left side of the git rev-parse HEAD result. I don't recall why I did that. Do you want the result of git rev-parse --short HEAD to be returned by core__lisp_implementation_id ?
13:57:56
yitzi
I don't think that externals-clasp really works anymore. I was never able to build using roswell also.
14:05:18
drmeister
::notify kpoeck On further investigation I don't know why I took the right 8-most characters from the git rev-parse --short HEAD output for the (core:lisp-implementation-id) I've changed it to 9 characters now. I've also added (core:clasp-git-full-commit) - it returns the full commit hash.
15:07:04
drmeister
The As, As_unsafe and IsA template functions take XXX_sp types as their template arguments.
15:11:48
drmeister
That generates compiler errors all over the place that tell me what the type To_SP::Type() is.
16:18:08
drmeister
Bike: Can you make this work with multiple-value-xxx forms? Here I'm trying to use LOOP and get double-float results out of the LOOP.
16:25:34
drmeister
The question is - how should we write this best and what do we need to support for code that we will find in the wild?
16:29:54
Bike
doing it with multiple-value-bind will take some work. it's sort of a different problem from the floats
16:34:18
Bike
writing it how you did with (multiple-value-bind (...) (... (values ...)) ...) is probably how it ought to be written
16:37:26
Bike
what the compiler needs there is i think two things... one, it should be able to infer types of multiple value call parameters in obvious cases like that
16:38:17
Bike
the former would at least mean you don't need to declare xx etc double-float outside of the loop
16:39:00
Bike
...and, the easier thing to deal with there, is that i haven't done any of these transforms for MAX yet
16:56:37
drmeister
I found the problem with the arithmetic that was causing some normals to be incorrect.
16:57:06
drmeister
The infix:infix macro is good when translating code from a language that uses infix.
17:35:46
Bike
the other easyish thing i can do is change how the contagion transforms work in such a way that the code shouldn't box in the loop even without the "of-type double-float"s, though it would do more type checks
17:43:14
drmeister
It generates a list of centroid/normal vectors for a collection of rings repeatedly
17:43:45
drmeister
It takes 2.8 seconds with the old compiler and 1.14 seconds with the new compiler.
18:03:33
Bike
i started on unboxed array access. seems like it should work. i hit a dumb roadblock for writing but ic an work around it
18:53:12
Bike
define an intrinsic or codegen sequence that takes a geom and outputs an unboxed double/float whatever, then hook it up with the transformers
18:55:36
Bike
say unboxed double exp. we have an intrinsic for it https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cmp/primitives.lsp#L234 define a bir primop https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cleavir/bir.lisp#L383 and a translation for it
18:55:36
Bike
https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cleavir/translate.lisp#L1065
18:56:04
Bike
and then finally define a transformer that turns (exp double-float) calls into a use of the primop https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cleavir/transform.lisp#L559
19:00:21
drmeister
What if you defined an intrinsic that reads a double from an integer offset from the start of an object?
19:01:07
Bike
if you gave a function like that the wrong kind of object you'd get some garbage double and it would probably be pretty confusing
19:01:51
drmeister
If we want to add these from extensions we need to hook them deep into the compiler - don't we?
19:01:56
Bike
also, for this case i don't think you'd actually need a transformer - you could just have a primop that inputs a geom object, checks the type, and outputs a double, and use that directly
19:02:24
Bike
like in this case a "here's an arbitrary C++ object, get this thing out of it" kind of operation
19:03:27
drmeister
I have a way for extensions to register initialization code. I can extend it to initialize stuff the compiler needs.
19:04:27
Bike
for this reading-from-an-object case you don't actually need any of this fancy type-directed translation stuff, anyway. you just need a primop that the compiler knows outputs an unboxed float
19:06:58
drmeister
Or what do you need from the extension support code that would make it not a problem.
19:07:09
Bike
the clasp-cleavir parts shouldn't mind a new primop being added after the fact, i don't think
19:08:08
drmeister
Intrinsics are defined in cmp/primitives.lsp - do primops need to use intrinsics?
19:08:53
Bike
no, they just need a translate-primop method that generates whatever code. e.g. this one https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cleavir/translate.lisp#L1091-L1095
19:15:32
drmeister
Sure, but that's an llvm instruction. If I want to generate a call instruction I thought it needs to be defined in primitives.lsp
19:16:36
drmeister
It's not a huge problem. I can add a mechanism where extensions register primitives when primitives are defined. I just want to make sure it's needed or otoh I'm misremembering things.
19:19:55
Bike
i think if you want a call to a named function it needs to be defined as an intrinsic, yes
19:21:57
Bike
for the particular case of getting things out of structures it might be good to define a general definition mechanism
19:22:57
Bike
like so we could write (define-structure geom:vec double double double), and then that lets you do (cmp:structure-read geom:vec 0) in code to get the x coordinate out
19:23:46
drmeister
I think the *primitives* dynamic variable is lazily set for every thread that is created.
19:28:22
Bike
oh, and (/ 1.0 (length points)) in your code is also going to box a float, but i can fix that one fairly easily
20:16:04
drmeister
The reason the primitives need to be defined in each thread is because the LLVMContext's are all thread local. The types that the primitives use as arguments are all defined relative to the thread local LLVMContext.
20:45:39
drmeister
And then have a function like (cmp:lookup-type :double) -> result of evaluating %double%
21:14:30
Bike
can we not also call c functions through ffi? does not that end up as an llvm named call?
21:16:18
drmeister
Hmm, maybe we could. I think I understand what we are doing here with primitives. I'm not so sure about ffi.
21:22:36
drmeister
ffi would go through dlsym - or we have to use load-time-value to lookup the dlsym.
21:35:25
drmeister
It's really straightforward to switch to type names like :double. I've switched over already.
21:36:19
drmeister
We can turn cmp:*primitives* into an atomic list and push new primitives into it at any time now I think.
21:46:35
Bike
i just noticed the wrong intrinsics were being used for exp and some others on doubles, so if you compile code with that an llvm assertion will fail and kill clasp
21:48:59
drmeister
I've changed all of the primitive definitions so they use keywords to represent the types like :double :t* etc.
21:49:40
drmeister
I've written a function (defun primitive-return-type (info) ...) and (defun primitive-argument-types (info)...) and they use the names to lookup the types at runtime and return them.
21:50:34
drmeister
Now I'll change the cmp::*primitives* dynamic variable so we don't have this complicated rigamarole where we redefine it for each thread.
22:10:23
Bike
(setf (row-major-aref a n) (exp (row-major-aref a n))) becomes "%2 = call float @cc_simpleFloatVectorAref(i8* %0, i8* 1); %3 = call float @llvm.exp.f32(float %2); call void @cc_simpleFloatVectorAset(float %3, i8* %0, i8* %1)". nice nice. apparently operator[] on arrays doesn't bounds check, though
22:18:25
drmeister
https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cmp/primitives.lsp#L45
23:32:15
drmeister
Bike: You are using cmp:%double% when you call (define-unary-primop core::df-exp "..." cmp:%double%) - can we switch this to use :double and lookup the type at runtime using (cmp:primitive-lookup-type :double)?
23:35:25
drmeister
Why do you have separate functions/macros for unary and binary operations? What about ternary and so on?
23:36:00
Bike
actually, %double% and so on are symbol macros, right? you could just change what they expand into without altering the code
23:36:14
Bike
no special reason for the different ones, and you can see a couple that don't quite fit