On Wed, Aug 22, 2018 at 06:14:24PM +0200, Duy Nguyen wrote: > On Wed, Aug 22, 2018 at 6:08 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > > > On Wed, Aug 22, 2018 at 6:03 PM Jeff King <peff@xxxxxxxx> wrote: > > > > > > On Wed, Aug 22, 2018 at 07:14:42AM -0400, Derrick Stolee wrote: > > > > > > > The other thing I was going to recommend (and I'll try to test this out > > > > myself later) is to see if 'the_hash_algo->rawsz' is being treated as a > > > > volatile variable, since it is being referenced through a pointer. Perhaps > > > > storing the value locally and then casing on it would help? > > > > > > I tried various sprinkling of "const" around the declarations to make it > > > clear that the values wouldn't change once we saw them. But I couldn't > > > detect any difference. At most I think that would let us hoist the "if" > > > out of the loop, but gcc still seems unwilling to expand the memcmp when > > > there are other branches. > > > > > > I think if that's the thing we want to have happen, we really do need to > > > just write it out on that branch rather than saying "memcmp". > > > > This reminds me of an old discussion about memcpy() vs doing explicit > > compare loop with lots of performance measurements.. > > Ah found it. Not sure if it is still relevant in light of multiple hash support > > https://public-inbox.org/git/20110427225114.GA16765@xxxxxxx/ Yes, that was what I meant. We actually did switch to that hand-rolled loop, but later we went back to memcmp in 0b006014c8 (hashcmp: use memcmp instead of open-coded loop, 2017-08-09). -Peff