https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84004
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
0 "vect" { xfail {vect_element_align} } } } */
but
# Return 1 if the target only requires element alignment for vector accesses
proc check_effective_target_vect_element_align { } {
so I'm not sure why we consider vect_element_align to be a reason to peel?
In fact we don't have a good target to test whether there's likely peeling.
Given the testcase in question:
__attribute__ ((noinline)) int
main1 (int n, float * __restrict__ pd, float * __restrict__ pa, float *
__restrict__ pb, float * __restrict__ pc)
{
int i;
for (i = 0; i < n; i++)
{
pa[i] = pb[i] * pc[i];
pd[i] = 5.0;
}
there are four refs and we can at most align one (unless IPA comes in the
way with LTO).
We have
r164941 | jules | 2010-10-04 16:59:30 +0200 (Mon, 04 Oct 2010) | 40 lines
gcc/testsuite/
* gcc.dg/vect/vect-42.c: Use vect_element_align instead of
vect_hw_misalign.
* gcc.dg/vect/vect-95.c: Likewise.
but vect_element_align is essentially vect_hw_misalign for most targets.
I'd say we should never peel this for alignment, that just doesn't make
sense. Some target costs models might disagree but we'll find out...
