Re: [Sbcl-devel] Contributing, peephole optimizer

[Gábor M. <me...@re...>]

On Thu, Aug 26, 2010 at 10:46 PM, Jonathan Smith
<jon...@gm...> 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.

> 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:ano...@sb...:/cvsroot/sbcl login
cvs -z3 -d:pserver:ano...@sb...:/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