> 1. The egg itself is not compiled with -O3, whereas if I link to > (chicken fixnum) I believe that these procedures will be inlined by the > CHICKEN compiler when the arrays egg is compiled with -O3 or higher.
That's correct. As -O3 implies "unsafe", the compiler can just ignore type checks and always inline numeric primitives. > > 2. There may be some rewriting rules that the compiler uses for > procedures in the (chicken ...) namespace that optimizes these directly > into their equivalent optimized C procedures. I'm not sure the compiler > has the same visibility if you re-export these from behind a module, and > especially not if you link dynamically (any hope of inlining those is > thus gone forever). As a general rule all renamings and rexports preserve the run-time semantics - as long as a procedure definition is not wrapped inside another procedure, the original procedure gets compiled and any optimizations and inlinings the compiler performs for "known" primitives will be applied. Syntax- and module-specific expansions perform renaming only and never introduce run-time code that wasn't explicitly given by the user. > > In fact on the latter point above, this raises an interesting question I > had for the mailing list: if I re-export a CHICKEN-specific procedure, > does the way the compiler handles translation units prevent certain > optimizations from applying? I've somewhat noticed that to be the case > but I haven't seen any writing about it nor have I understood the extent > to which that might affect certain SRFIs or eggs. See above - unless something is wrapped, you get the inlining. But as I see in the SRFI-143 spec, their operations take any number of arguments, where the ones from (chicken fixnum) have arity 2, so I assume the srfi code wraps the primitives into multi-argument procedures and thus preserves imports from the srfi-143 module to be inlined. > > > If you have time/energy, it would be useful to make Chicken's > > implementation do what it was originally intended. See the > > "Implementation" section in the SRFI, or feel free to ask me for > > explanations of details. One approach would be to extend those exports from (chicken fixnum) that match the multi-argument operations from srfi-143 and make the compiler aware of these, internally expanding the multi-arg cases into nested applications of inline calls to the 2-argument C runtime primitive ops. > It might also be a good idea to enforce SRFI-143's behaviour around > overflow / underflow as part of CHICKEN's default behaviour in CHICKEN > 6, but I don't really know how I would get started having that discussion. The SRFI-page doesn't seem to specify any behaviour. The runtime system is compiled with "-fwrapv" in the hope to preserve wrapping semantics for integer arithmetic, but I'm not sure how reliable that is. cheers, felix
