freenode/#sbcl - IRC Chatlog
Search
13:37:03
stassats
(declaim (inline inl)) (defun inl (x) x) (defun a (x) (declare ((unsigned-byte 64) x)) (logcount (inl x)))
15:27:47
borodust
mhm, libclang seems to cause a memory corruption in SBCL always around address 0x3e80000xxxx
15:35:55
borodust
minimal repro case: https://gist.github.com/borodust/c7ffa83e89f007f3d4f998b1decb8b00 (100% on my machine)
18:06:45
karlosz
stassats: yeah, inlining interacts badly with block compilation right now. CMUCL did it right but the inlining code hjas changed a lot
18:07:24
karlosz
when you block compile, you generally don't need to inline though because local calls are fast and dont cause code bloat
18:07:53
karlosz
if you make some of the functions "static" i.e. make them not entry points, they can get let converted and other good stuff
18:09:49
karlosz
causes 2x code size for no reason, whereas let converting the once use defun is a win
18:12:45
karlosz
heres the (real-world) use case people ask it for: https://sourceforge.net/p/sbcl/mailman/message/3493226/
18:53:08
stassats
i already split the file in two, i suppose it needs to split further, to define inlined functions outside
19:14:06
stassats
doesn't appear to be an easy place to say "don't block compile this inlined function"
19:30:14
karlosz
there are a few places in the cmucl build (like the ir1tran-lambda stuff) that used to be block compiled in cmucl which could probably be done In SBCL too
19:31:01
karlosz
i'm not sure if there's a nice way to achieve the form-granularity block compilation cmucl does
19:31:47
karlosz
i think it is possible to get block compile to behave nicely with inlining, something with find free-funs getting thje right functoinal
19:32:25
stassats
ub32 basher consing ub64, i want to create a new entry point, accepting a single ub32 and concatenating it
19:32:43
karlosz
i was thinking of extending build-order-lisp.expr to allow specifying :block compile and :entry-point