This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/43052] [4.7 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i486-linux-gnu              |x86_64-*-*, i?86-*-*
                 CC|                            |rth at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org
   Target Milestone|---                         |4.7.0
            Summary|Inline memcmp is *much*     |[4.7 Regression] Inline
                   |slower than glibc's         |memcmp is *much* slower
                   |                            |than glibc's, no longer
                   |                            |expanded inline

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-24 10:56:00 UTC ---
Since

2011-08-12  Nick Clifton  <nickc@redhat.com>

        * builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi pattern.
        * doc/md.texi (cmpstrn): Note that the comparison stops if both
        fetched bytes are zero.
        (cmpstr): Likewise.
        (cmpmem): Note that the comparison does not stop if both of the
        fetched bytes are zero.

we no longer expand memcmp inline as x86 does not have a cmpmemsi pattern.

Testcase:

int foo(char *s, char *q)
{
  return memcmp (s, q, 4);
}

the 1-size case is folded to *s == *q.

This is now a regression, we have to do _something_ about it for 4.7,
at least for constant small sizes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]