Add support for generating HTML/man documentation
add header dependencies
fix bench compilation/warning
Port from original snappy. Add unaligned 64bit copy for ARM architectures.

Enable the use of unaligned loads and stores for ARM-based architectures
where they are available (ARMv7 and higher). This gives a
significant speed boost on ARM, both for compression and decompression.
It should not affect x86 at all.
Avoid 64bit loads on 32bit pltforms

Port from snappy SVN

For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).

The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Add more ARM exceptions

Port from snappy SVN

Mark ARMv4 as not supporting unaligned accesses (not just ARMv5 and
ARMv6); apparently Debian still targets these by default, giving us
segfaults on armel.
Change some ORs to plus

Port from snappy SVN

Change a few ORs to additions where they don't matter. This helps the
compiler use the LEA instruction more efficiently, since e.g. a + (b << 2)
can be encoded as one instruction. Even more importantly, it can constant-fold the
COPY_* enums together with the shifted negative constants, which
also saves some instructions. (We don't need it for LITERAL, since it happens
to be 0.)

I am unsure why the compiler couldn't do this itself, but the theory
is that it cannot prove that len-1 and len-4 cannot underflow/wrap, and thus
can't do the optimization safely.
Increase block size to 64k

Ported from snappy SVN

    Increase the Zippy block size from 32 kB to 64 kB, winning ~3% density
    while being effectively performance neutral.

    The longer story about density is that we win 3-6% density on the benchmarks
    where this has any effect at all; many of the benchmarks (cp, c, lsp, man)
    are smaller than 32 kB and thus will have no effect. Binary data also seems
    to win little or nothing; of course, the already-compressed data wins nothing.
    The protobuf benchmark wins as much as ~18% depending on architecture,
    but I wouldn't be too sure that this is representative of protobuf data in
    general.

    As of performance, we lose a tiny amount since we get more tags (e.g., a long
    literal might be broken up into literal-copy-literal), but we win it back with
    less clearing of the hash table, and more opportunities to skip incompressible
    data (e.g. in the jpg benchmark). Decompression seems to get ever so slightly
    slower, again due to more tags. The total net change is about as close to zero
    as we can get, so the end effect seems to be simply more density and no
    real performance change.

    The comment about not changing kBlockSize, scary as it is, is not really
    relevant, since we're never going to have a block-level decompressor without
    explicitly marked blocks. Replace it with something more appropriate.

    This affects the framing format, but it's okay to change it since it basically
    has no users yet.
    [AK: I hope that's true for snappy-c too. Famous last words ...]
avoid sign extension

Port from snappy SVN

    Make the two IncrementalCopy* functions take in an ssize_t instead of a len,
    in order to avoid having to do 32-to-64-bit signed conversions on a hot path
    during decompression. (Also fixes some MSVC warnings, mentioned in public
    issue 75, but more of those remain.) They cannot be size_t because we expect
    them to go negative and test for that.

    This saves a few movzwl instructions, yielding ~2% speedup in decompression.
we are uptodate now with snappy 1.1.0
add makefile target for ftracer
more checking in sgverify
rename UnalignedCopy64 to lower case style
move all return -EIO to separate lines