>> 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.
That's true. >> 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. Right, of course. There is also another way of fixing the problem, which might actually be easier to implement and which sounds sensible to me: declaring an identifier "inline" can be handled identical to declaring it "local". This would mean that the procedure is potentially inlinable (we declare that it isn't changed from code outside of this commpilation unit) and the normal inlining behaviour applies, that is, the procedure is inlined if it fulfills the usual criteria and its size is below the inline-limit). So that would be a SHOULD. No changes to the inlining itself need to be done, recursive inlining is allowed (until the inline-limit is reached) and all call sites will be visited, since the inlining of a procedure may take place in multiple optimization passes, due to cascading optimizations. Forced inlining can then be done via "define-inline", at least if the call-sites are inside the current compilation unit. cheers, felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
