diff options
author | snappy.mirrorbot@gmail.com <snappy.mirrorbot@gmail.com@03e5f5b5-db94-4691-08a0-1a8bf15f6143> | 2013-01-04 11:54:20 +0000 |
---|---|---|
committer | snappy.mirrorbot@gmail.com <snappy.mirrorbot@gmail.com@03e5f5b5-db94-4691-08a0-1a8bf15f6143> | 2013-01-04 11:54:20 +0000 |
commit | f1d5be35642968c2e5b1eb729d619ea38b915abc (patch) | |
tree | da73bb9379b43b2588c46437aa29154c265dc7ac | |
parent | c3e036dbe6a0da2da8c59fcc1d1a86fc3c7ab3ec (diff) | |
download | snappy-f1d5be35642968c2e5b1eb729d619ea38b915abc.tar.gz |
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.
The gains are small but measurable; 0.5-1.0% over the BM_Z* benchmarks
(measured on Westmere, Sandy Bridge and Istanbul).
R=sanjay
git-svn-id: http://snappy.googlecode.com/svn/trunk@69 03e5f5b5-db94-4691-08a0-1a8bf15f6143
-rw-r--r-- | snappy.cc | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -202,10 +202,10 @@ static inline char* EmitCopyLessThan64(char* op, size_t offset, int len) { if ((len < 12) && (offset < 2048)) { size_t len_minus_4 = len - 4; assert(len_minus_4 < 8); // Must fit in 3 bits - *op++ = COPY_1_BYTE_OFFSET | ((len_minus_4) << 2) | ((offset >> 8) << 5); + *op++ = COPY_1_BYTE_OFFSET + ((len_minus_4) << 2) + ((offset >> 8) << 5); *op++ = offset & 0xff; } else { - *op++ = COPY_2_BYTE_OFFSET | ((len-1) << 2); + *op++ = COPY_2_BYTE_OFFSET + ((len-1) << 2); LittleEndian::Store16(op, offset); op += 2; } |