[Zlib-devel] [PING] Improve longest_match performance

[Jan Seiffert]

John Reiser schrieb:
> On 07/24/2012 03:37 PM, Jan Seiffert wrote:
[snip]
>>
>> But it can also be the other way round, that was the reason for his regression
>> on Core2.
>> And he wants an unsigned type (there is no negative indexing going on), because
>> the sign extension is killing s/390. ptrdiff_t is a signed type.
> 
> Using ptrdiff_t for cur_match and wmask does work [assuming no compiler errors.]

I never said ptrdiff_t does not work.
But it may generate suboptimal code (by being signed, by being to large).
(i really like ptrdiff_t, but not for this task)

> The only appearances of 'wmask' are:
>     uInt wmask = s->w_mask;
>     } while ((cur_match = prev[cur_match & wmask]) > limit)
> 
> We know that pcur_match < 32K because index 32768 is outside the window.
> Also 0 <= .w_mask <= 0x7FFF.  Therefore _both_ operands of the AND have
> bit 15 [and above] clear, so the result of the AND is non-negative at
> any width >=16, regardless of signed or unsigned.
> 

We know that, but not the compiler.

>> as already mentioned in and ff:
>> http://mail.madler.net/pipermail/zlib-devel_madler.net/2012-July/002931.html
> 
> Please give a specific citation and quote a line or two.

Sorry, i lost a little context.
http://mail.madler.net/pipermail/zlib-devel_madler.net/2012-June/002907.html
Second Paragraph:
"The code currently generated for longest_match looks far from optimal
due to a bunch of pointless zero/sign extend instructions."

Then the disassembly at the end. And take the code/changes into account
The trick is:
a) losing sign extends by using unsigned types
b) losing zero extends by using a wider (register sized) type

Advice given in 002931.html and ff has to be seen in that light.

Greetings
	Jan

-- 
A camel is a horse designed by a committee