The A- implementation
only uses 4 peephole patterns.  The generated code is pretty bad when
compared with <code>javac</code>.  There are many more patterns that
can help the optimizer reduce the size of the generated bytecode.

For this deliverable you must repeatedly examine the Jasmin assembly
(.j) files produced by the A- and A+ joos compilers, identify as many peephole
patterns as you can, and implement them following the templates in
<a href="https://github.com/mcgill-comp520-2013/mcgill-comp520-2013.github.io/blob/master/joos/a-/patterns.h">patterns.h</a>.
As you implement
patterns and shrink the generated code, you will find even more
patterns that you can exploit.

You should examine <a href="https://github.com/mcgill-comp520-2013/mcgill-comp520-2013.github.io/blob/master/joos/a-/optimize.c"><code>
optimize.c</code></a> to see the various primitives you can use in
your patterns.  In particular, a pattern may only use the given
operations on the goto graph and the <code>makeCODExxx</code>
constructors defined in <a href="https://github.com/mcgill-comp520-2013/mcgill-comp520-2013.github.io/blob/master/joos/a-/tree.h"><code>tree.h</code></a>.
Extensions are of course possible, but they must be clearly documented.

You will be graded on the 2009 JOOS benchmarks, however you can also try your optimizations
with the 2010 and 2011 benchmarks if that helps (all of them are in the GitHub repository).
We expect you to at least reach the A+ compiler. Anything better would be nice.

<p>
See the <a href="howtopeepholeopt.html">instructions</a> for running the benchmarks.
</p>

You should check in the following:
<ul>

<li>Modifications to your <code>patterns.h</code> file, for each optimization
you should add a comment explaining why it is sound.

<li>A file called <code> compile.log </code> showing the results of
running the <code>compile_and_run_opt</code> script on
the <a href="https://github.com/mcgill-comp520-2013/mcgill-comp520-2013.github.io/blob/master/joos/benchmark/2009/joos/">2009 class set of
benchmarks</a>.  
Your log file must show that all benchmarks compile correctly,
verify correctly, and run with the correct output.  This means that
there must be no differences between the expected output and what each
optimized benchmark produces.
Making sure the patterns operate correctly on your benchmarks is
necessary, but not sufficient.  In addition, we will be manually
checking your patterns are sound in general, removing any unsound
patterns, and rerunning all of the benchmarks if necessary.

<li>A file called <code>size</code> containing the result of running
the <code>totalbytes</code> command on the .j files produced by
your final A- compiler with your peephole optimizations enabled.  This
size is determined by compiling your .j file into a .class file and
then decompiling that .class file into a .sj file using dejava.
</ul>