[Bug target/23605] memset() Optimization on x86-32 bit

[Bug target/23605] memset() Optimization on x86-32 bit

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
               Host|Kernel 2.6.12               |
         Resolution|                            |WONTFIX
              Build|-g -O0                      |

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-11 14:21:28 UTC ---
Unclear state of this bug.  We likely have newer dups if there is an issue.

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2006-09-18 01:45 -------
(In reply to comment #13)
> Notice in the tektester.386.s testcase, you have an xor instruction on ebx,
> when all what's needed to clear out al/ax/eax is a
> mov  $0, al/ax/eax
xor is both faster and has a smaller encoding than mov does.


-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2005-11-02 17:16 -------
All P1 enhancements not targeted towards 4.1, moving to P5.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P5


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

[Bug target/23605] memset() Optimization on x86-32 bit

[kevin at planetsaphire dot com]

------- Additional Comments From kevin at planetsaphire dot com  2005-08-29 00:36 -------
Also, is setting %eax to $0 once per memset good enough?  I don't think the
"stos" instruction would reset %eax...  the resulting assembly code in
tektester.386.s is the same in -O3 and -O2...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug target/23605] memset() Optimization on x86-32 bit

[kevin at planetsaphire dot com]

------- Additional Comments From kevin at planetsaphire dot com  2005-08-29 00:16 -------
err... I meant "get rid of the pushpop instructions for ebx" because ebx
wouldn't be used (probably taken care of automatically anyway)

-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2005-08-28 23:36 -------
The generated code for your second test case doesn't look too bad to me.  The
bulk of the code is checking the alignment of the buffer in order to get an
efficient rep; stosl.  What would you recommend as faster code?

-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2005-08-28 23:15 -------
I didn't realize that this was at -O0.  Extra register moves at -O0 are not a
bug.  -O0 means no optimization.

I think it is odd that we open code memset at -O0 but not at -O1.  I don't know
the rationale behind that.  The comment in the code explaining why we don't open
code this case by default is:

      /* In case we don't know anything about the alignment, default to
         library version, since it is usually equally fast and result in
         shorter code.

But that does not explain why we open code at -O0.  I think the open coding at
-O0 is most likely a bug, as -O0 code should emphasize debuggability, and open
coding prevents the user from setting a breakpoint.

As pinskia says, the -minline-all-stringops option forces the call to be
opencoded.  And I agree with him that the bug report about extra register moves
at -O0 is invalid.  If you want optimal code, compile with optimization.

-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-28 23:00 -------
Oh, I forgot to mention if you want to inline all string functions, use -minline-all-stringops.

-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-28 22:21 -------
First it is not our bug your distro installs i686 versions, go bug them instead.
Second glibc not using SSE is its bug and not ours, report it to them instead.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/23605] memset() Optimization on x86-32 bit

[kevin at planetsaphire dot com]

------- Additional Comments From kevin at planetsaphire dot com  2005-08-28 21:58 -------
(In reply to comment #6)
> inlining memset is not an optimization as most OS's memsets are better than
the inlined version, using 
> sse registers,etc.

I have finished reviewing over the glibc memset.* source files for the 32-bit
Intel platforms, simply because every one using Linux is using glibc as the
"libc".  I find that SSE (nor even MMX) is used in the 32-bit implementations of
memset.

I think it is best to change this bug into an enhancement for the next available
GCC branch.  The reason for this change is because of a few reasons:

1. Fedora Core 3 (the distro installed on my computer) does not install the i686
binaries of glibc during install; rather, it installs the i386 version.

2. You are right about systems having better memset()s, though considering the
widespread use of glibc, most implementations do not utilize SSE, MMX, etc. 
Maybe the memset() optimization can be turned on by the use of a new flag? 
After all, the i386 build of glibc does not include the use of instructions that
can possibly be used on i686.  In addition, there may be a few circumstances
where the user may not want to use the i686 build, such as debugging, apps that
require the i386 build (perhaps to get around a few glibc bugs), and hardware
processor issues with other functions in glibc.

I hope the GCC staff and the steering committee reviews over this possible
enhancement seriously.  The optimization would allow the user to get around
slower code in certain situations when it comes to using memset().

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |enhancement
             Status|RESOLVED                    |UNCONFIRMED
           Priority|P2                          |P1
         Resolution|INVALID                     |


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

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-28 20:37 -------
inlining memset is not an optimization as most OS's memsets are better than the inlined version, using 
sse registers,etc.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/23605] memset() Optimization on x86-32 bit

[kevin at planetsaphire dot com]

------- Additional Comments From kevin at planetsaphire dot com  2005-08-28 20:34 -------
(In reply to comment #4)
> You are compiling at -O0 so this is not a bug and we don't care that much
about code generation at 
> -O0.

So you're invalidating this bug because -O0 optimizes this and -O2 does not?  I
think this is clearly a bug, and so does Ian Lance Taylor per his e-mail earlier.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-28 20:28 -------
You are compiling at -O0 so this is not a bug and we don't care that much about code generation at 
-O0.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/23605] memset() Optimization on x86-32 bit

[kevin at planetsaphire dot com]

------- Additional Comments From kevin at planetsaphire dot com  2005-08-28 20:26 -------
(In reply to comment #1)
> Are you compiling your source at -O0 or GCC at -O0?  If the former, then this
is most likely not a bug.

-O2 does not do any optimization at all, and -O0 optimizes the code to a certain
extent.  The testcase I submitted was compiled with the -O0 flag.



-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[kevin at planetsaphire dot com]

------- Additional Comments From kevin at planetsaphire dot com  2005-08-28 20:18 -------
Created an attachment (id=9604)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9604&action=view)
Testcases and .i Files of uchar.*

This attatchment contains only the source files of my project, as well as the
.i files of uchar.*

-- 


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

[Bug target/23605] memset() Optimization on x86-32 bit

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-28 20:08 -------
Are you compiling your source at -O0 or GCC at -O0?  If the former, then this is most likely not a bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target


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