This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
- From: "rdapp at linux dot vnet.ibm.com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 01 Jun 2017 08:08:58 +0000
- Subject: [Bug tree-optimization/80925] [8 Regression] vect peeling failures
- Auto-submitted: auto-generated
- References: <bug-80925-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #7 from rdapp at linux dot vnet.ibm.com ---
I could reproduce the fails on a power8 machine now.
Looking at the vect-28.c FAIL now - the loop to be vectorized is:
for (i = 0; i < N; i++)
{
ia[i+off] = 5;
}
It still gets vectorized but not peeled anymore because the costs for no
peeling equal the costs for peeling (for unknown alignment). Costs for an
unaligned store are the same (1) as for a regular store so this is to be
expected.
At first sight, the situation is similar for vect-87.c, vect-88.c and maybe
most of the fails with '"Vectorizing an unaligned access" 0'.
How should we deal with this? If the cost function is correct as it is and
unaligned stores are not slower at all, I don't think we should be peeling.
What is expected for real workloads and unaligned loads/stores?