[Bug c++/56493] [4.8/4.9/5 Regression] Performance regression in google dense hashmap

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Richard Biener from comment #17)
> > Btw, I think that
> > 
> > (int) ((long unsigned int) q + D.2078)
> > 
> > to
> > 
> > (int) ((unsigned int) q + (unsigned int) D.2078)
> > 
> > doesn't look like an always profitable pattern on GIMPLE (more stmts).  Also
> > take into consideration what targets PROMOTE_MODE (mode-of-q/D.2078) do
> > and prefer types according to that.
> > 
> > The vectorizer prefers single type sizes throughout computations to avoid
> > re-packing.
> 
> Which is why the proposal was to do demotion early and promote back
> depending on machine description (and, perhaps on separate IL copy, in
> between ifcvt and vectorizer also promote to decrease re-packing).  The
> demotion would help with avoiding unnecessary computations (e.g. those
> affecting just the high bits), canonicalizing the IL and in some cases
> allowing bigger parts of computations with the same type bitsizes, and
> promotion would be an attempt to help with sub-word arithmetics on word only
> arithmetics targets, etc.
> Dunno why Kai has stopped working on that :(.

Because I pushed back hard.  He ended up with multiple passes here and there,
and mostly motivated things by better folding with less conversions in the IL.

I also think you can't really separate demotion and promotion (demotion
is just making range information a little bit more "explicit" in the IL,
and thus IMHO tied to VRP if it runs).  Promotion (which can of course also
be effective demotion if legal) is to make things aligned with the target.