On 7 April 2010 04:40, Paul Khuong <pvk@...> wrote:
> the post scriptum) I've said it before, it's only because of the relative naïveté of our
> middle-end that we haven't yet had to provide, e.g., a memory model: the optimised output
> will always perform exactly the side-effects and (non-elided) reads as written in the
> CL, I believe a compiler should really focus on eliminating the abstraction overhead
> associated with the language. Analysing dynamic types away falls under that goal.
> Moreover, I find that being able to construct a mental model of how a compiler will
> transform one's code is usually much more important that the output's performance. Python
I mostly agree. I think that eliminating language and abstraction
overhead is more important than typical C&D flow optimizations, and I
do think that there is great value in being able to model the compiler
in your head.
> A priori, I am opposed to introducing complex (read "global") rewrites. I find even common
> subexpression elimination somewhat suspect in a general-purpose compiler, never mind loop
^- this I don't quite agree with, however. While the sentiments in the
first part guide my own work, I don't feel comfortable saying "we
don't want no stinking code motion in SBCL".
If and when patches that implement optimizations which reorder or
merge operations (lift them out of loops, do CSE, whatever) appear, I
think we should then ask ourselves: "when and how to enable these?"
Maybe there will be call for (declare (pragma code-motion)) some day.
What I seriously want to avoid is telling people interested in both
SBCL and optimizing compilers that their efforts are not needed, or
that their skills are unappreciated.
(Though quite possibly we should go over optimization wishlist items
on launchpad, and comment on their role, or eg. have a document which
discusses them in doc/internals-notes.)