diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2025-03-07 10:18:35 +0000 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2025-03-07 10:18:35 +0000 |
commit | e8651b80aeb86da935035e218747a6b41b611497 (patch) | |
tree | 51cbaaa16d212e2d2fdacb645b2fa24afe1b08b5 /gcc/tree-vectorizer.h | |
parent | 5ae621e2e86c00d1fb13ef6839d0c3bace762ac8 (diff) | |
download | gcc-e8651b80aeb86da935035e218747a6b41b611497.zip gcc-e8651b80aeb86da935035e218747a6b41b611497.tar.gz gcc-e8651b80aeb86da935035e218747a6b41b611497.tar.bz2 |
vect: Enforce dr_with_seg_len::align precondition [PR116125]
tree-data-refs.cc uses alignment information to try to optimise
the code generated for alias checks. The assumption for "normal"
non-grouped, full-width scalar accesses was that the access size
would be a multiple of the alignment. As Richi notes in the PR,
this is a documented precondition of dr_with_seg_len:
/* The minimum common alignment of DR's start address, SEG_LEN and
ACCESS_SIZE. */
unsigned int align;
PR115192 was a case in which this assumption didn't hold. The access
was part of an aligned 4-element group, but only the first 2 elements
of the group were accessed. The alignment was therefore double the
access size.
In r15-820-ga0fe4fb1c8d78045 I'd "fixed" that by capping the
alignment in one of the output routines. But I think that was
misconceived. The precondition means that we should cap the
alignment at source instead.
Failure to do that caused a similar wrong code bug in this PR,
where the alignment comes from a short bitfield access rather
than from a group access.
gcc/
PR tree-optimization/116125
* tree-vect-data-refs.cc (vect_prune_runtime_alias_test_list): Make
the dr_with_seg_len alignment fields describe tha access sizes as
well as the pointer alignment.
* tree-data-ref.cc (create_intersect_range_checks): Don't compensate
for invalid alignment fields here.
gcc/testsuite/
PR tree-optimization/116125
* gcc.dg/vect/pr116125.c: New test.
Diffstat (limited to 'gcc/tree-vectorizer.h')
0 files changed, 0 insertions, 0 deletions