2010/8/27 Gábor Melis <mega@retes.hu>
On Thu, Aug 26, 2010 at 10:46 PM, Jonathan Smith
<jonathansmith415@gmail.com> wrote:
> Hi,
> I've been working on implementing a peephole optimizer for SBCL.
> (http://sbcl-internals.cliki.net/Peephole%20Optimizer)

Wow, that's cool. I think people would be interested and perhaps even
provide some feedback if you publish what you have even if it's
preliminary.


Okay, I have put a  TGZ of my current folder up on Sourceforge.

It is from a fork of sbcl 1.0.40
https://sourceforge.net/projects/sbcl-peep-opt/files/

The majority of the changes are in Codegen.lisp and assem.lisp in the compiler.
Currently it compiles with a really, really dumb implementation of a single optimization.

There is also a file called 'peephole.lisp' which is intended to eventually be used as the compile-time pattern matcher.
It is also in the compiler folder, but is not loaded during the compile (mostly because of not-doneness).

----

Pretty much all we do is buffer assembly instruction structures, label structures, and alignments (as lambdas), into lists,
and then using a closure of the 'instruction (or label) emitter' which is contained within the structure, we can emit them to a segment at any point...

----

The main thing that I am having difficulty understanding now is how exactly TNs map onto machine registers, memory locations, etc.

I have a general idea, but it seems that in certain situations, my expectations are violated.
It is possible that using TNs as the basis for peephole optimization could lead to a more powerful (different?) version of peephole optimization than standard regex pattern matching (You may have information about what registers are dead, and when, for example).

The other issue, is that this is my first foray into assembly language programming,
so I am not exactly full of insight as to what optimizations are actually optimizations...

----

I apologize for the primitive delivery of the code, I will see about setting up something with git or CVS later today,
 and possibly merge it with a more recent version of SBCL.

> I have a few questions about the process of contributing, (once it is a bit
> further along):
> 1.) How do I contribute? The project page (link to sourceforge) on sbcl.org
> is a dead link for me. "This page has been deprecated and is now controlled
> by the consume team". I was lucky that i was already subscribed to the
> SBCL-devel mailing list in my gmail, as I had difficulty finding it on the
> site. I expect that the procedure is to fork the main branch and merge in my
> changes, and that they then get considered for addition? Where is the main
> branch?

The official cvs is on sourceforge.

http://sourceforge.net/projects/sbcl/develop

The link works for me, in case it still doesn't work for you:

cvs -d:pserver:anonymous@sbcl.cvs.sourceforge.net:/cvsroot/sbcl login
cvs -z3 -d:pserver:anonymous@sbcl.cvs.sourceforge.net:/cvsroot/sbcl co -P sbcl

That said, most devs use the git gateway these days:

git://sbcl.boinkor.net/sbcl.git
http://sbcl.boinkor.net/git/sbcl.git


> 2.) It seems like these types of changes are pretty important to really,
> really test thoroughly.
> (judging by the number of times I have landed myself in LDB working on this
> stuff).
> Is there a list of commonly-used applications that I could run to test the
> compiler?
> (I was thinking I would try MAXIMA for starters).

Anything with an extensive test suite is valuable. CL-PPCRE comes to
mind. Still, I think it may happen that an innocent transformation
changes semantics slightly by for instance optimizing away a piece of
code that acted as a memory barrier. Maybe there are less contrived
examples. Anyway, it would be nice to have a way to quickly glance
through differences in the assembly for a set of functions (maybe
functions that belong to a particular package).

> 3.) These changes would be applicable to all architectures (I think), I've
> made the changes only within the generic sections of the compiler (with the
> notable exception that the optimizations are platform specific). I only have
> an x86_64 machine currently, I can test regular x86 on it, but I cannot
> test, for example, SPARC or MIPS on it. Is there a procedure for doing this?

You may want to get an account on the gcc compile farm (as some of us did):

http://gcc.gnu.org/wiki/CompileFarm

> (An emulator, perhaps?).
> That's it for now, I think
> Thanks,
> -Jon

Cheers,
Gabor

I forgot about the GCC compiler farm, that will certainly do the trick.
I'll sign up for it.

Thanks,

-Jon