https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I believe it is incorrect ALIGN info as can be seen in the
-fdump-tree-all-alias dumps.
Seems with current trunk on x86_64-linux and
-g -quiet -mtune=amdfam10 -O3 pr65450.f90
the problematic memory load which should have been movupd and is movapd instead
is using _3571:
# ALIGN = 32, MISALIGN = 0
vectp.499_3571 = vectp.499_1481 + 64;
which has been created by aprefetch pass from:
# ALIGN = 32, MISALIGN = 0
vectp.499_135 = vectp.499_1480 + 16;
which has been created by pcom pass from:
# ALIGN = 32, MISALIGN = 0
vectp.499_1480 = vectp.499_1481 + 16;
which has been created during vectorization by vect_create_data_ref_ptr ->
create_iv -> make_ssa_name for dr:
#(Data Ref:
# bb: 43
# stmt: _1095 = MEM[(real(kind=8)[0:D.3649] *)_558][_1094];
# ref: MEM[(real(kind=8)[0:D.3649] *)_558][_1094];
# base_object: MEM[(real(kind=8)[0:D.3649] *)_558];
# Access function 0: {_1086 + 3, +, 1}_41
#)
- _1480 is indx_after_incr.
The base_object is indeed 32 byte aligned:
# RANGE [-64424509440000, 60000] NONZERO 18446744073709551600
_557 = _556 * 30000;
# PT = { D.3692 } (nonlocal)
# ALIGN = 32, MISALIGN = 0
_558 = &u[_557];
- u is a common aligned to 32 bytes:
static real(kind=8) u[90000];
and 30000 is divisible by 16, and it is ARRAY_REF, so the offset from &u[0] is
a multiple of 128 bytes. But that doesn't tell anything about what values
_1094 can have.
I see vect_create_addr_base_for_vector_ref already always overrides the
align/misalign info after duplicating DR_PTR_INFO, and so does bump_vector_ptr,
but vect_create_data_ref_ptr trusts DR_PTR_INFO. But from what I can
understand, it is just the points to info, and alignment info in there is
solely for the base address, but not necessarily for the whole DR.
Richard, do you agree? Now the question is what we can do here, if in all the
spots in vect_create_data_ref_ptr we should just set it to unknown alignment,
or if we can do better (and how).
