From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-469333-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28392 invoked by alias); 3 Dec 2014 10:34:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 28165 invoked by uid 48); 3 Dec 2014 10:34:24 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/56493] [4.8/4.9/5 Regression] Performance regression in google dense hashmap
Date: Wed, 03 Dec 2014 10:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56493-4-tYxRp7qOOO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56493-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56493-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00340.txt.bz2

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 :(.