[Bug c/43052] Inline memcmp is *much* slower than glibc's

[Bug c/43052] Inline memcmp is *much* slower than glibc's

[m.j.thayer at googlemail dot com]

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

Michael T. <m.j.thayer at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m.j.thayer at googlemail
                   |                            |dot com

--- Comment #2 from Michael T. <m.j.thayer at googlemail dot com> 2010-10-01 11:08:11 UTC ---
Unless I read those benchmarks wrong, they say that for unaligned memory the
inline byte-by-byte version is almost always faster.  So surely a multi-byte
inline version should at least do an alignment check before proceeding.  I
don't know if it would still be worth inlining then.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |hubicka at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-11-10 21:17:09 UTC ---
Mine.  I think we should go for the rep movq. Ideally we should track the
alignment from calloc call to use, perhaps by fusing the loops, but I am just
day dreaming with that ;))

 I will take a look.

Honza

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-11-10 21:36:07 UTC ---
Hmm, I should read testcases curefully. It is memcmp. GCC is not really smart
on inlining this; I guess we should just disable the inline unless we optimize
for size since we don't really have enough info to inline it well by default.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |Serge.Pavlov.at.gnu at
                   |                            |gmail dot com

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2010-11-11 02:24:28 UTC ---
String/memory functions in the current glibc are VERY FAST,
especially for larger data size under all cases. Gcc should
inline only small/known data size. We are investigating this.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-11 10:39:35 UTC ---
(In reply to comment #4)
> Hmm, I should read testcases curefully. It is memcmp. GCC is not really smart
> on inlining this; I guess we should just disable the inline unless we optimize
> for size since we don't really have enough info to inline it well by default.

We can still inline for very small known sizes where the call overhead
would outweight any optimization in glibc.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-11 11:46:43 UTC ---
Speaking of memcmp/strcmp, perhaps we on the other side should inline for !-Os
commonly used comparisons like
if (strcmp (p, ".") == 0 || strcmp (p, "..") == 0)
  continue;

glibc has a macro for this, but I think it would be preferable to do it in gcc
where we know about -Os, cold basic blocks etc.

Currently we only fold if (strcmp (p, "")) ...

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[justin.lebar+bug at gmail dot com]

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

Justin Lebar <justin.lebar+bug at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |justin.lebar+bug at gmail
                   |                            |dot com

--- Comment #8 from Justin Lebar <justin.lebar+bug at gmail dot com> 2011-06-13 18:09:07 UTC ---
I just did some tests, and on my machine, glibc's memcmp is faster even when
the size of the thing we're comparing is 4 bytes.  I can't point to a case that
this optimization speeds up on my machine.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|Serge.Pavlov.at.gnu at      |sergos.gnu at gmail dot com
                   |gmail dot com               |

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> 2011-06-13 18:14:26 UTC ---
The basic string/memory functions in glibc 2.13 or above are
super faster in all cases.  GCC can't beat glibc if function
call overhead is low.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[justin.lebar+bug at gmail dot com]

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

--- Comment #10 from Justin Lebar <justin.lebar+bug at gmail dot com> 2011-06-13 18:18:13 UTC ---
Can I force gcc not to use its inlined version?

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hubicka at gcc dot gnu.org]

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.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-07-04 10:49:18 UTC ---
Created attachment 24670
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24670
memcpy/memset testing script

HJ,
can you please run the attached script with new glibc as 
sh test_stringop 64 640000000 gcc -march=native | tee out

In my quick testing on glibc2.11 and core i5 & AMD machine, inline
memcpy/memset is still win on I5 for all blocks sizes (our optimization table
is however wrong since it is inherited from generic one). For blocks of 512b
and above however the inline code is about as fast as glibc code and obviously
longer.

On AMD machine libcall is win for blocks of 1k to 8k. For large blocks inline
seems to be win again, for whatever reason. Probably prefetch logic is wrong on
the older glibc.

If glibc stringops has been finally made sane, we ought to revisit the tables
we generate inline versions from.

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[justin.lebar+bug at gmail dot com]

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

--- Comment #13 from Justin Lebar <justin.lebar+bug at gmail dot com> 2011-07-04 14:40:40 UTC ---
(In reply to comment #12)
> Created attachment 24670 [details]
> memcpy/memset testing script
> 
> HJ,
> can you please run the attached script with new glibc as 
> sh test_stringop 64 640000000 gcc -march=native | tee out

Do you think you could spin a script which also tests memcmp?

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[justin.lebar+bug at gmail dot com]

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

--- Comment #14 from Justin Lebar <justin.lebar+bug at gmail dot com> 2011-07-04 15:00:36 UTC ---
Created attachment 24676
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24676
Test results from my core i7

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> 2011-07-05 11:08:50 UTC ---
> 
> Do you think you could spin a script which also tests memcmp?
memcmp is different story.  Few years back I rewrote memcpy/memset codegen to
allow choosing
from several basic implementations based on size. The script I attached is
basically
testing the individual algorithm so you can set for each CPU target a table
choosing best
performing one for given size.

memcmp is still produced in very stupid way.  Sane inline implementations of
memcmp are harder than memcpy/memset.  I will try to look into it and how
current recommended codegens look for AMD/Intel chips.

Honza

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

[rguenth at gcc dot gnu.org]

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.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-08-24 14:20:29 UTC ---
Hmm,
I guess ideally the middle-end should know how to inline the simple loop (for
both strlen and memcmp) and do so when object size is known to be small
(probably by target specific value). Or does anyone think it is a bad idea?

We could then make i386 backend to again inline the rep instruction and/or the
new string extensions

Honza

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

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-24 14:36:45 UTC ---
(In reply to comment #17)
> Hmm,
> I guess ideally the middle-end should know how to inline the simple loop (for
> both strlen and memcmp) and do so when object size is known to be small
> (probably by target specific value). Or does anyone think it is a bad idea?

I think that's a bad idea, yes.  Apart from maybe simple cases we already
handle for memcpy -> assignment simplifications (thus, aligned compares up to
word_mode size), but supposedly only if the result is checked for ==/!= 0
only(?).

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

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

[fabio.ped at libero dot it]

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

Fabio <fabio.ped at libero dot it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fabio.ped at libero dot it

--- Comment #19 from Fabio <fabio.ped at libero dot it> 2011-12-21 16:35:41 UTC ---
Just FYI: mesa is now defaulting to -fno-builtin-memcmp to workaround this
problem:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=983fa4ad523535debf2e94cf6ac1fd4c5630c0d2
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1448bdf1c0995e3ac2e0f97c51e5e2d73eded8e0

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.0                       |4.7.1

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-22 08:27:12 UTC ---
GCC 4.7.0 is being released, adjusting target milestone.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.1                       |4.7.2

--- Comment #21 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-14 08:36:17 UTC ---
GCC 4.7.1 is being released, adjusting target milestone.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.2                       |4.7.3

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:19:50 UTC ---
GCC 4.7.2 has been released.

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

[steven at gcc dot gnu.org]

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

--- Comment #23 from Steven Bosscher <steven at gcc dot gnu.org> 2013-03-13 20:13:32 UTC ---
Honza, ping?

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.3                       |4.7.4

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-11 07:59:26 UTC ---
GCC 4.7.3 is being released, adjusting target milestone.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

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

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|hubicka at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #27 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I won't be able to do anything iwth this for 5.0, so I am unassigning myself.
Will try to keep this on my radar for next stage1 though.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

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

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4