On Sat, Aug 28, 2010 at 3:07 PM, Nathan Froyd <froydnj@gmail.com> wrote:
On Sat, Aug 28, 2010 at 1:56 PM, Jonathan Smith
<jonathansmith415@gmail.com> wrote:
> 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/

Next time a diff would be preferable.  Even if it's against an old
version (so long as the version is not ancient).

Ok, I will do it that way next time!
> 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.

TNs represent machine registers and memory locations (such as stack
slots).  It's hard to help you with your understanding/expectations
since you haven't explained exactly what they are.

Right, that is pretty much my understanding up until this point.
I meant to indicate that I just need to read more of the source code.

> 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).

Certainly.  There are peephole patterns that are only valid if you
know that certain registers are dead after the sequence, for example.

It's encouraging to see this work done.  I personally would have done
it slightly differently; I know there are people who favored your
approach.  However it gets done, it will be nice to groan slightly
less when looking at DISASSEMBLE output. :)

This seemed like the 'least resistance' approach to me, and I admit is is kind of a hack at this stage.

What would be your preferred alternative?