This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/77536] New: Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data
- From: "pthaugen at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 08 Sep 2016 20:42:46 +0000
- Subject: [Bug tree-optimization/77536] New: Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536
Bug ID: 77536
Summary: Vectorizer not maintaining relationship of relative
block frequencies in absence of real profile data
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc64*-unknown-linux-gnu
Target: powerpc64*-unknown-linux-gnu
Build: powerpc64*-unknown-linux-gnu
// gcc -O3 -ffast-math -mcpu=power8 -mrecip=all -S test.c
void sub(float *restrict x, float *restrict y, float *restrict z, int n)
{
int i;
for (i = 0; i < n; i++)
x[i] = z[i]/y[i];
}
In the dump before vectorizer (148t.ifcvt) the loop block has freq=8500 which
is almost 6X the freq of the entry block(1500). After vectoriztion the now
vectorized loop block has freq=662. While I agree the freq of the loop block
should drop some after vectorization, it should still maintain the relationship
of being the hottest block in the function.