[Bug c++/56493] Performance regression in google dense hashmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #14 from Uroš Bizjak ubizjak at gmail dot com --- According to Comment #0 and Comment #9, this PR should be confirmed as a regression from 4.6.
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30312 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30312action=edit gcc49-pr56493.patch Untested patch that in the FE restores the performance on the simplified testcase. Haven't tried the original. Of course, having this optimization be performed in GIMPLE will be much more worthwhile, but likely not backportable.
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktietz at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- The reduced testcase has been slowed down by r176072, aka PR45437. If you want to speed it up by source code changes, q += (unsigned int) f(i); would do instead of q += f(i);, or you can do q = q + f(i);. Before that bugfix, the C++ FE produced (void) (q = (int) ((unsigned int) f (i) + (unsigned int) q)) which is generally wrong (say if q was addressable and f could modify it), after it we generate (void) (q = TARGET_EXPR D.2078, f (i);, (int) ((long unsigned int) q + D.2078);) The question is why the narrowing of the operation (to be done on unsigned int rather than long unsigned int) isn't performed here, that is something we do right now solely in the FE. There are PRs (PR45397 and PR47477) about lack of type demotion (and promotion) on GIMPLE, but don't know what the current state of that is.
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 jim at meyering dot net changed: What|Removed |Added CC||jim at meyering dot net --- Comment #12 from jim at meyering dot net --- Thank you, Jakub.
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #9 from Christopher Berner cberner at fb dot com 2013-04-13 01:37:27 UTC --- Created attachment 29864 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29864 Simple test case Here's an even simpler test case. It seems that there's a fairly serious regression with inlining. Even adding the attribute always_inline doesn't seem to restore performance. However, manually inlining the code with a macro restores performance to gcc 4.6 level
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #10 from Andrew Gallagher andrewjcg at gmail dot com 2013-04-13 01:44:27 UTC --- I did several attempts at bisecting this. Whenever I (hackily) reverted the change which caused the regression, it just popped up a few hundred revs later. This seems to be gcc assigning new weights to functions, which determines whether the functions is early inlined or not. So I *think* this is really an early inlining v. late inlining issue, and we happened to get lucky with the weights that 4.6 selected (I don't think there is a really effective way for gcc to predict how subsequent optimizations will/can benefit by early inlining). Also, as far as I can see, there is no way to force early inlining (other than switching to macros).
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-09 10:57:06 UTC --- Thanks for bisecting it
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #7 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-09 04:17:39 UTC --- I was able to bisect this to http://gcc.gnu.org/viewcvs?view=revisionrevision=172430. I haven't had time to dig in further, but that rev looks like it has plenty of inlining changes, which makes sense.
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #1 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 13:11:30 UTC --- Created attachment 29561 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29561 Sample program using dense hashmap
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #2 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 13:12:41 UTC --- I also see this same perf regression on trunk (as of r195725).
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-01 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 14:29:24 UTC --- Instead of expecting everyone who looks at this bug to find and download the dense hash map code please provide preprocessed source as requested in the bug reporting guidelines that you were prominently asked to read before you entered this bug report: http://gcc.gnu.org/bugs/
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #4 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 22:09:10 UTC --- Created attachment 29565 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29565 Preprocessed test program source
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #5 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 22:10:14 UTC --- Ah, sorry. Just attached preprocessed sources now (which had to be compressed to it in the 1K size limit).
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-02 00:56:53 UTC --- thanks
