Search
Saturday, 15th of February 2020, 18:06:59 UTC
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:08:44
karlosz
imagine everything is stuffed into labels
18:09:19
karlosz
we have some "once use" defuns that are marked inline in the compiler
18:09:49
karlosz
causes 2x code size for no reason, whereas let converting the once use defun is a win
18:10:13
karlosz
also, allows a FACTORIAL function to not call itself through an FDEFN
18:12:45
karlosz
heres the (real-world) use case people ask it for: https://sourceforge.net/p/sbcl/mailman/message/3493226/
18:51:51
stassats
well, it just makes it unsuitable for the code that uses inlining
18:53:08
stassats
i already split the file in two, i suppose it needs to split further, to define inlined functions outside
18:56:25
stassats
but the bashers themselves use inlining, no go
18:56:46
stassats
block compilation should just be fixed
19:14:06
stassats
doesn't appear to be an easy place to say "don't block compile this inlined function"
19:14:30
stassats
i suppose i could split !define-byte-bashers
19:29:27
karlosz
oh, are you by chance trying to block compile during the build?
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:30:38
karlosz
one of the cmucl todo items was the block compile more of the system
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:35
stassats
karlosz: both, during the build and not
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:31:51
stassats
but planning on using it in the build in the end
19:31:59
stassats
the problem |3b| reported
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
19:33:01
karlosz
right, anywhere that benefits from a locall convention instead
19:38:51
stassats
now i can't factor out a bit of !define-byte-bashers into a macro
19:44:30
stassats
is sb-fasteval broken or what
19:48:52
stassats
why can't i use a macro inside another macro then
19:59:08
stassats
to hell with it then, i'll just copy-and-paste
20:11:01
stassats
block compilation doesn't survive cold init
20:12:14
stassats
a function doesn't get defined
20:14:18
stassats
probably not collecting top level forms
0:12:19
karlosz
OK, yeah, inlining + block compilation works desirably on cmucl
Sunday, 16th of February 2020, 6:06:59 UTC