[Bug c++/56493] Performance regression in google dense hashmap

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.