Re: [Chicken-hackers] inliner bug

[John Cowan]

Felix scripsit:

> It is irrelevant what Common Lisp says - a declaration can nearly
> always be considered a SHOULD, and a compiler may very well decide
> to inline something which has been declared notinline if it can prove
> that the semantics don't change.

Mmm, fair enough.  However, I would consider such a declaration an
indication to the compiler that its proof is not considering sufficient
evidence.  For example, if we have a tracer or debugger at runtime,
we may want to suppress inlining, no matter what the compiler thinks it
knows, so that we can detect every call to the procedure.

> (and that particular case your mentioning - special declarations -
> can be considered one of the most spectacular warts of CL)

Oh, sure.  It was a matter of keeping old dynamically scoped code
running with the minimum of grief while switching to lexical scope
everywhere else.  Still, Scheme has found it necessary to reinvent
special variables in the (much better) form of parameters.

> So the question is rather: what is more intuitive or what may actually
> confuse the user? And on that line of argument I agree with you
> completely that the current behaviour is not that great.

I would strengthen that:  an infinite loop in the compiler can't possibly
be what the user wants.

> Recursive inlining may be desired, BTW. In a TCO-optimized language
> this is the same as loop-unrolling.

Loop unrolling is equivalent to recursive inlining to a finite depth,
either because the loop has a known termination point, or because
the compiler sets an arbitrary cutoff.  Open-ended recursive inlining
is equivalent to a C compiler trying to unroll a while-loop into an
infinitely long procedure, because after all it might never terminate.

One possibility would be to make an assumption about the size of the L2
instruction cache, and never inline a procedure that looks to be larger
than that cache.  Inlining primarily trades space for speed, but once
your code has blown the cache, you are no longer winning.

-- 
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
                   --Felix Winkelmann