* APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit @ 2005-08-28 23:37 Kevin McBride 2005-08-29 2:05 ` Daniel Berlin ` (4 more replies) 0 siblings, 5 replies; 9+ messages in thread From: Kevin McBride @ 2005-08-28 23:37 UTC (permalink / raw) To: gcc Everyone, Please take notice that I am appealing my bug (number 23605) to the steering committee of GCC on the basis that it is a legimate bug/enhancement in need of a through research. I believe that Andrew Pinski is trying to keep the research from occuring by means of marking the bug as invalid. I am hoping that the steering committee will order a through research on the bug. There are times when it might be best to have things like memset() inlined by the compiler itself, as outlined in my latest comment to the bug. - KJM -------- Original Message -------- Subject: [Bug target/23605] memset() Optimization on x86-32 bit Date: 28 Aug 2005 22:21:15 -0000 From: pinskia at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org To: kevin@planetsaphire.com References: <20050828200424.23605.kevin@planetsaphire.com> ------- 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 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-28 23:37 APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit Kevin McBride @ 2005-08-29 2:05 ` Daniel Berlin 2005-08-29 4:50 ` Ian Lance Taylor ` (3 subsequent siblings) 4 siblings, 0 replies; 9+ messages in thread From: Daniel Berlin @ 2005-08-29 2:05 UTC (permalink / raw) To: Kevin McBride; +Cc: gcc On Sun, 2005-08-28 at 18:48 -0400, Kevin McBride wrote: > Everyone, > > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. The Steering committee really doesn't get involved in bug reports. Your only recourse is public shaming. Sorry. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-28 23:37 APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit Kevin McBride 2005-08-29 2:05 ` Daniel Berlin @ 2005-08-29 4:50 ` Ian Lance Taylor 2005-08-29 22:20 ` Richard Henderson 2005-08-29 6:59 ` Joe Buck ` (2 subsequent siblings) 4 siblings, 1 reply; 9+ messages in thread From: Ian Lance Taylor @ 2005-08-29 4:50 UTC (permalink / raw) To: Kevin McBride; +Cc: gcc Kevin McBride <kevin@planetsaphire.com> writes: > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. I believe that Andrew > Pinski is trying to keep the research from occuring by means of marking > the bug as invalid. > > I am hoping that the steering committee will order a through research on > the bug. There are times when it might be best to have things like > memset() inlined by the compiler itself, as outlined in my latest > comment to the bug. I'm sure we all look forward to receiving orders from the steering committee. As pinskia noted, later, in the PR, you want the -minline-all-stringops option, which is documented. In the meantime, I think there may be a bug here, in that memset is open coded for the i386 at -O0. That doesn't make sense to me; e.g., it prevents setting a breakpoing on memset. This happens in this conditional in ix86_expand_clrmem: if ((!optimize || optimize_size) && (count == 0 || ((count & 0x03) && (!optimize_size || (count & 0x03) + (count >> 2) > 7)))) /* do cld; stos */ This conditional dates back to here: Tue Jan 11 16:26:47 MET 2000 Jan Hubicka <jh@suse.cz> ... (cld pattern): New. (movstrsi, clrstr, cmpstr, strlen expander): Emit cld instruction (movstrsi_1, clrstrsi_1, cmpstrsi_1, strlensi_1, cmpstrsi_nz_1 insn): Do not output cld instruction Any thoughts on this? Ian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-29 4:50 ` Ian Lance Taylor @ 2005-08-29 22:20 ` Richard Henderson 0 siblings, 0 replies; 9+ messages in thread From: Richard Henderson @ 2005-08-29 22:20 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Kevin McBride, gcc On Sun, Aug 28, 2005 at 04:29:56PM -0700, Ian Lance Taylor wrote: > In the meantime, I think there may be a bug here, in that memset is > open coded for the i386 at -O0. That doesn't make sense to me; e.g., > it prevents setting a breakpoing on memset. This, IMO, has nothing to do with i386. If we don't want to open-code memset at -O0, we should have avoided transforming this such that we call to clear_storage in the first place. r~ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-28 23:37 APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit Kevin McBride 2005-08-29 2:05 ` Daniel Berlin 2005-08-29 4:50 ` Ian Lance Taylor @ 2005-08-29 6:59 ` Joe Buck 2005-08-29 8:00 ` [DEAD] " Kevin McBride 2005-08-29 23:26 ` Mike Stump 2005-08-30 0:03 ` Joe Buck 4 siblings, 1 reply; 9+ messages in thread From: Joe Buck @ 2005-08-29 6:59 UTC (permalink / raw) To: Kevin McBride; +Cc: gcc On Sun, Aug 28, 2005 at 06:48:17PM -0400, Kevin McBride wrote: > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. I believe that Andrew > Pinski is trying to keep the research from occuring by means of marking > the bug as invalid. I've looked at the bug in bugzilla; it's not marked as invalid, though I tend to agree with Andrew and Ian's comments in the log. In any case, the SC doesn't get involved in cases like this. And even if the SC lost its sanity and decided to micromanage Bugzilla as you ask, it would take a 3/4 vote, and you certainly wouldn't get mine. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [DEAD] APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-29 6:59 ` Joe Buck @ 2005-08-29 8:00 ` Kevin McBride 2005-08-29 20:02 ` Daniel Berlin 0 siblings, 1 reply; 9+ messages in thread From: Kevin McBride @ 2005-08-29 8:00 UTC (permalink / raw) To: Joe Buck; +Cc: gcc, r0cko Joe Buck wrote: > I've looked at the bug in bugzilla; it's not marked as invalid, though > I tend to agree with Andrew and Ian's comments in the log. I set the bug back to unconfirmed after I noticed that, in my opinion, there can be more optimization done. > In any case, the SC doesn't get involved in cases like this. And even > if the SC lost its sanity and decided to micromanage Bugzilla as you > ask, it would take a 3/4 vote, and you certainly wouldn't get mine. I didn't realize that the SC had no control over Bugzilla. Unless there was something I missed, all what the web site said was: > In April 1999 the steering committee was appointed by the FSF as the > official GNU maintainer for GCC and changed its name to GCC steering > committee. All I can now say is: If no one on the GCC team wants to fully investigate my bug, then there's nothing I can do about the bug except to implement the fix in my own code. This appeal started up over misunderstandings between Andrew Pinski, Ian Lance Taylor, and I. I felt that Ian Lance Taylor agreed with me prior to submitting the bug to the bug tracker, and so, felt humiliated by Andrew Pinski's comments. When Ian Lance Taylor stepped in, he made the misunderstanding obvious to me, and so, I did what I could to see if gcc was performing optimizations as much as possible. This appeal is now dead. Let's get on with our projects, regardless if my bug report will ever be turned into a bug fix. - KJM ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [DEAD] APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-29 8:00 ` [DEAD] " Kevin McBride @ 2005-08-29 20:02 ` Daniel Berlin 0 siblings, 0 replies; 9+ messages in thread From: Daniel Berlin @ 2005-08-29 20:02 UTC (permalink / raw) To: Kevin McBride; +Cc: Joe Buck, gcc, r0cko On Mon, 2005-08-29 at 01:33 -0400, Kevin McBride wrote: > Joe Buck wrote: > > I've looked at the bug in bugzilla; it's not marked as invalid, though > > I tend to agree with Andrew and Ian's comments in the log. > > I set the bug back to unconfirmed after I noticed that, in my opinion, > there can be more optimization done. > > > In any case, the SC doesn't get involved in cases like this. And even > > if the SC lost its sanity and decided to micromanage Bugzilla as you > > ask, it would take a 3/4 vote, and you certainly wouldn't get mine. > > I didn't realize that the SC had no control over Bugzilla. Unless there > was something I missed, all what the web site said was: > > > In April 1999 the steering committee was appointed by the FSF as the > > official GNU maintainer for GCC and changed its name to GCC steering > > committee. Yes, they control the overall direction. They don't micromanage. > > All I can now say is: > > If no one on the GCC team wants to fully investigate my bug, then > there's nothing I can do about the bug except to implement the fix in my > own code. If you want to see what's up, feel free. Nobody will stop you. If you want to propose a patch, feel free. As for "no one on the GCC team", you seem to have a misunderstanding about how GCC ends up working. It's not like we have people paid who go through all the enhancement requests or something. The fact that the bugs are in Bugzilla is just a way to track bugs. It does not in any way guarantee that your bug will be looked at, regardless of whether it is open, closed, invalid, not invalid, etc. There is no guarantee that your bug will or won't be fixed for a certain release, etc, unless *you* start submitting the patches to fix it. Certainly, there are certain classes of bugs that are more likely to be looked at than others, etc. In addition, there are some people who are more attentive to certain pieces of the compiler than others, and will go looking for enhancement requests in bugzilla to fix. This is not by stretch of the imagination something that people do across the board. In other words, the best way to get a bug attention is generally to give that bug attention yourself. The other day we had someone who believed that if we marked his bug "enhancement" instead of "minor", it was "misclassifying" and would cause havoc. The reality is that nobody was going to fix his bug anytime soon, regardless of how it was marked, because he wasn't going to, and it just wasn't high priority. > > This appeal started up over misunderstandings between Andrew Pinski, Ian > Lance Taylor, and I. I felt that Ian Lance Taylor agreed with me prior > to submitting the bug to the bug tracker, and so, felt humiliated by > Andrew Pinski's comments. At the risk of Andrew hating me (:P), this, sadly, is not the first time someone has taken offense at his comments in a bug. You shouldn't take it personally. > When Ian Lance Taylor stepped in, he made the > misunderstanding obvious to me, and so, I did what I could to see if gcc > was performing optimizations as much as possible. > > This appeal is now dead. Let's get on with our projects, regardless if > my bug report will ever be turned into a bug fix. Again, if you want a bug fix, your best course of action is to fix it :) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-28 23:37 APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit Kevin McBride ` (2 preceding siblings ...) 2005-08-29 6:59 ` Joe Buck @ 2005-08-29 23:26 ` Mike Stump 2005-08-30 0:03 ` Joe Buck 4 siblings, 0 replies; 9+ messages in thread From: Mike Stump @ 2005-08-29 23:26 UTC (permalink / raw) To: Kevin McBride; +Cc: gcc On Aug 28, 2005, at 3:48 PM, Kevin McBride wrote: > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. Ok, so go research it, collect data, and then report your findings back. For example, benchmark an entire linux distro with your patch in and out, and tell us what the performance is, go measure spec, tell us what the performance is, benchmark CSiBE... > I am hoping that the steering committee will order a through research You have been so ordered, let us know how it goes. :-) > on the bug. Another approach would be to take definitive measurements, for example, at -Os if one way is 30 bytes and the current approach gcc takes is 31 bytes, then that is a `bug'. If you can show that a testcase takes fewer clock cycles and is smaller than the current codegen, file _that_ bug, include the numbers of ticks for each, give details, a vague, I wonder if this is better, isn't going to be as persuasive as hard numbers. Failing all that you can appeal by hiring someone that will do the research, and report back their findings. I hope this helps. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit 2005-08-28 23:37 APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit Kevin McBride ` (3 preceding siblings ...) 2005-08-29 23:26 ` Mike Stump @ 2005-08-30 0:03 ` Joe Buck 4 siblings, 0 replies; 9+ messages in thread From: Joe Buck @ 2005-08-30 0:03 UTC (permalink / raw) To: Kevin McBride; +Cc: gcc On Sun, Aug 28, 2005 at 06:48:17PM -0400, Kevin McBride wrote: > I am hoping that the steering committee will order a through research on > the bug. Kevin, what you don't seem to understand is that the SC can't order anyone to do anything. The SC has no employees, doesn't sign paychecks. GCC is a volunteer organization. True, a number of contributors draw a salary from their companies for their GCC work, but their management, not the SC, tells them what to work on. The SC does have some powers: it can refuse to allow certain kinds of changes into GCC, approves release plans put forward by the release manager, and approves the people who will be maintainers to various parts of the compiler. Once in its entire history, the SC banned someone from its mailing lists (this was back in the egcs days, and the guy was a complete whacko who made escalating threats against the release manager, including "I'm going to force your company to fire you" and "I've found out where you live"). But even if the SC were persuaded that you are entirely correct, the most it could do would be to ask for a volunteer to research your bug. And your bug is only one of 3,114 currently open gcc bugs (according to a Bugzilla query I just did), and I am unpersuaded that it is a particularly important one. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-08-29 23:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-08-28 23:37 APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit Kevin McBride 2005-08-29 2:05 ` Daniel Berlin 2005-08-29 4:50 ` Ian Lance Taylor 2005-08-29 22:20 ` Richard Henderson 2005-08-29 6:59 ` Joe Buck 2005-08-29 8:00 ` [DEAD] " Kevin McBride 2005-08-29 20:02 ` Daniel Berlin 2005-08-29 23:26 ` Mike Stump 2005-08-30 0:03 ` Joe Buck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).