libera/#clasp - IRC Chatlog
Search
18:40:12
drmeister
You would have to know how long the list will be - and that cannot be determined until you run it.
18:41:16
drmeister
Will I need to make these kind of declarations? (let ((det-max (max det-x det-y det-z))) (declare (double-float det-max)) ...)
18:43:15
Bike
no, it should be able to infer that the result of max on doubles is a double, though i haven't put that in yet
18:43:44
drmeister
Your idea for DX analysis sounds very, very interesting. That could impact a lot of existing code.
18:44:32
Bike
actually, looking at the compiler macro on max it might know it's a double already, but i can check
18:44:55
drmeister
cracauer told me this morning that his recollection is that you have to declare dynamic extent on anything dynamic extent.
18:45:25
Bike
"SBCL has fairly extensive support for performing allocation on the stack when a variable is declared dynamic-extent. The dynamic-extent declarations are not verified, but are simply trusted as long as sb-ext:*stack-allocate-dynamic-extent* is true. " says the manual
18:45:52
Bike
a dx analysis is something beach has wanted for a while, since it means being able to stack allocate without relying on potentially inaccurate declarations (or at least different potentially inaccurate declarations)
18:47:02
Bike
also, with map, how it would have to work is it computes the length of the list at runtime based on the input lists, and stack allocates that
18:47:48
drmeister
CL_DEFMETHOD void OVector3_O::crossProduct_BANG_(const Vector3& other, Vector3& result )
18:47:57
drmeister
CL_DEFUN void geom__v_PLUS__BANG_(const Vector3& x, const Vector3& y, Vector3& result )
18:49:25
drmeister
Have I mentioned in the last five minutes how excited I am by these developments? Tremendously.
18:51:46
Bike
the way karlosz wrote it it just charges forward, which is naive, but reasonably quick and works fine for this arithmetic stuff where inputs depend on previous results
19:23:49
Bike
ok it does look like the compiler understands max well enough already, at least for simple cases
20:04:31
Bike
ok, now i get "error: use of undeclared identifier 'CLASP_GIT_FULL_COMMIT'" from unboxed-floats with my stuff merged in
20:14:11
Bike
we do do some weird crap with calling conventions, but i don't think we have any assembly, no
20:27:16
Bike
drmeister: i defined some defprimop macros. the simplest one, when it just calls an intrinsic, looks like this https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cleavir/primop.lisp#L166-L186
22:58:35
cracauer
are you sure the latest is all pushed to branch unboxed-floats? My Mac builds but fails to start with:
22:58:51
cracauer
JIT session error: Symbols not found: [ _wrapped_core__convert_overflow_result_to_bignum_Fixnum_sp ]
2:08:41
drmeister
If I'm in the unboxed-floats branch and I do: git pull origin main and I merge the commits. What have I done?
2:33:39
Bike
you got the rtype backwards - you want ((:double-float) :object) meaning it takes an object and returns a double
2:34:03
Bike
and defvprimop doesn't define a special operator itself. you can do (core::primop geom:%vx ovec) though
2:34:52
Bike
also you could just have the C++ bodies be gc::As<geom::OVector3_sp>(vec3)->_Value[whatever]; and it will do a nice type error for you
2:49:54
drmeister
Since beginnings are important - can you change it to: (return-value (arguments...))
2:54:16
drmeister
Actually that compile error was on zeus and on there I'm running it under udb to try and get a backtrace.
3:08:49
Bike
like, ((:single-float :single-float) :single-float :single-float) means it takes two single floats as arguments, and then returns two single floats
3:27:09
Bike
you could have one that returns all three values from an ovec, but it probably wouldn't be too useful, at least at the moment
4:06:44
Bike
um, also it looks like you still have the rtype wrong, though that's not what's causing this
4:09:07
Bike
try wrapping the defvprimop-intrinsics in (eval-when (:compile-toplevel :load-toplevel :execute
4:11:49
drmeister
This is unrelated (probably) and downstream but it happened again - now on my mac...
4:12:37
Bike
i was thinking maybe we should check argument types in irc-intrinsic so we get a normal error instead of llvm killing everythign
4:12:49
drmeister
I don't think so - it first surfaced on zeus and I haven't put these primops on there.
4:15:30
Bike
i could throw that into the macro i guess, but then it would need to know whether it unwinds as well
4:22:21
Bike
if that's coming from the primop type resolution thing maybe it should signal an error instead of returning nil
4:27:51
drmeister
Something about registering object files and the GDB jit interface slows udb way, way down.
4:31:03
Bike
for reference, if i'm understanding the eval-when solution correctly, the problem is that the inline ast is generated at compile time, before the vprimop is actually defined
4:40:21
drmeister
https://github.com/clasp-developers/clasp/blob/unboxed-floats/src/lisp/kernel/cmp/cmpir.lsp#L1390
4:54:55
karlosz
::notify Bike i don't know if meta-evaluate is the best place to analyze dx. the idea of meta-evaluate is that it partially evaluates a syntax tree, which inherently corresponds to a forward pass over a graph - use the data from a previous operation to optimize the next
4:57:49
karlosz
::notify Bike the only backwards thing it does is code flushing. i was thinking dx probably would go with constraint propagation, since that works backwards from assertions to uses. if i remember correctly i never ported the limited constraint pass from hir to bir. but i would say dx fits naturally into a constraint framework. sbcl does dx analysis totally wrong; DX wasn't part of the original design
4:59:22
karlosz
::notify Bike sbcl's support was cribbed partially from cmucl when it was added there in 2003; the dx funargs database hasn't even been ported over to sbcl yet