This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/43052] Inline memcmp is *much* slower than glibc's
- From: "hubicka at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 4 Jul 2011 10:12:49 +0000
- Subject: [Bug target/43052] Inline memcmp is *much* slower than glibc's
- Auto-submitted: auto-generated
- References: <bug-43052-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-07-04 10:11:03 UTC ---
H.J,
if glibc implementation beats gcc even for size of 4, I guess we could just
drop the pattern or enable at at -Os only.
Or are there easy cases we want to inline, like we do for memcpy?
Unlike memcpy, memcmp/strcmp is more difficult to handle because the amount of
memory it will process is harder to estimate. I guess still with known
alignment and/or small upper bound of object size, inline code would be a win.