On 01/15/2016 09:58 AM, Bernd Schmidt wrote:
PR43052 is a PR complaining about how the rep cmpsb expansion that gcc
uses for memcmp is slower than the library function. As is so often the
case, if you investigate a bit, you can find a lot of issues with the
current situation in the compiler.
This PR was accidentally fixed by a patch by Nick which disabled the use
of cmpstrnsi for memcmp expansion, on the grounds that cmpstrnsi could
stop looking after seeing a null byte, which would be invalid for
memcmp, so only cmpmemsi should be used. This fix was for an out-of-tree
target.
I believe the rep cmpsb sequence used by i386 would actually be valid,
so we could duplicate the cmpstrn pattern to also match cmpmem and be
done - but that would then again cause the performance problem described
in the PR, so it's probably not a good idea.
One question Richard posed in the comments: why aren't we optimizing
small constant size memcmps other than size 1 to *s == *q? The reason is
the return value of memcmp, which implies byte-sized operation
(incidentally, the use of SImode in the cmpmem/cmpstr patterns is really
odd). It's possible to work around this, but expansion becomes a little
more tricky (subtract after bswap, maybe). Still, the current code
generation is lame.
So, for gcc-6, I think we shouldn't do anything. The PR is fixed, and
there's no easy bug-fix that can be done to improve matters. Not sure
whether to keep the PR open or create a new one for the remaining
issues. For the next stage1, I'm attaching a proof-of-concept patch that
does the following:
* notice if memcmp results are only used for equality comparison
against zero
* if so, replace with a different builtin __memcmp_eq
* Expand __memcmp_eq for small constant sizes with loads and
comparison, fall back to a memcmp call.
The whole thing could be extended to work for sizes larger than an int,
along the lines of memcpy expansion controlled by move ratio etc. Thoughts?
Seems generally reasonable to me. I've looked at that BZ more than once
and thought "ewww, I don't want to touch this mess", so I'm more than
happy to have you taking the lead on it.
Jeff
