| Newsgroups |
gmane.lisp.scheme.chicken |
| Message-ID |
<[email protected]> |
> 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