public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tjw at omnigroup dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug optimization/14042] C++ abstraction penalty is high in simple cases Date: Fri, 06 Feb 2004 16:57:00 -0000 [thread overview] Message-ID: <20040206165705.31946.qmail@sources.redhat.com> (raw) In-Reply-To: <20040206074537.14042.tjw@omnigroup.com> ------- Additional Comments From tjw at omnigroup dot com 2004-02-06 16:57 ------- s1 and s2 are different objects since they are on the stack. 'inS1' and 'inS2' could be the same object since they are passed by reference, but that is immaterial here since they are copied into the stack allocated objects and then written over with the results after the loop. That is, inside the loop, only stack allocated objects are used and it should be easy to prove that they are not the same object. Maybe you are saying that the compiler doesn't currently keep track of whether they are different objects? Also, I believe this bug persists if you change the signature to: void iterate_bad(State inS1, State inS2, unsigned int n) ... and what is even more interesting is that even though the function doesn't produce any useful work once that is done (assuming inlining takes effect) and the whole function could be replaced by a 'blr', it isn't (I think I only tried this on 3.4, YMMV on tree-ssa). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14042
next prev parent reply other threads:[~2004-02-06 16:57 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-02-06 7:45 [Bug c++/14042] New: " tjw at omnigroup dot com 2004-02-06 7:46 ` [Bug c++/14042] " tjw at omnigroup dot com 2004-02-06 7:50 ` [Bug c++/14042] C++ abstraction penalty is high in simple Altivec cases tjw at omnigroup dot com 2004-02-06 7:53 ` tjw at omnigroup dot com 2004-02-06 8:00 ` [Bug optimization/14042] C++ abstraction penalty is high in simple cases pinskia at gcc dot gnu dot org 2004-02-06 15:05 ` segher at kernel dot crashing dot org 2004-02-06 16:57 ` tjw at omnigroup dot com [this message] 2004-02-09 10:52 ` segher at kernel dot crashing dot org 2004-02-09 19:08 ` pinskia at gcc dot gnu dot org 2004-02-20 2:54 ` dberlin at gcc dot gnu dot org 2004-02-20 2:56 ` dberlin at gcc dot gnu dot org 2004-03-03 5:52 ` pinskia at gcc dot gnu dot org 2004-03-06 4:00 ` tjw at omnigroup dot com 2004-03-06 4:08 ` pinskia at gcc dot gnu dot org 2004-05-13 20:25 ` [Bug tree-optimization/14042] " pinskia at gcc dot gnu dot org 2004-05-16 23:46 ` tjw at omnigroup dot com 2004-05-16 23:59 ` pinskia at gcc dot gnu dot org 2004-05-17 13:30 ` pinskia at gcc dot gnu dot org 2004-05-27 8:02 ` pinskia at gcc dot gnu dot org 2004-06-02 4:41 ` pinskia at gcc dot gnu dot org 2004-06-02 18:57 ` pinskia at gcc dot gnu dot org 2004-06-02 18:57 ` cvs-commit at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040206165705.31946.qmail@sources.redhat.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).