https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92534
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, the fix for PR91790 was indeed incorrect. But the whole realignment code
is somewhat "old"...
Ideally we'd move the vect_setup_realigment code down to after we computed
the dataref_ptr here:
/* 1. Create the vector or array pointer update chain. */
if (j == 0)
{
...
else if (first_stmt_info_for_drptr
&& first_stmt_info != first_stmt_info_for_drptr)
{
dataref_ptr
= vect_create_data_ref_ptr (first_stmt_info_for_drptr,
aggr_type, at_loop, offset, &dummy,
gsi, &ptr_incr, simd_lane_access_p,
byte_offset, bump);
/* Adjust the pointer by the difference to first_stmt. */
data_reference_p ptrdr
= STMT_VINFO_DATA_REF (first_stmt_info_for_drptr);
tree diff
= fold_convert (sizetype,
size_binop (MINUS_EXPR,
DR_INIT (first_dr_info->dr),
DR_INIT (ptrdr)));
dataref_ptr = bump_vector_ptr (dataref_ptr, ptr_incr, gsi,
stmt_info, diff);
and feed it the dataref_ptr directly.
Probably first refactor vect_setup_realignment into two pieces, one for the
!compute_in_loop and one for the compute_in_loop case.
Guess I'll revert the fix for PR91790 for now.
Note the issue in that PR is that first_stmt_info_for_drptr provides
the DR that needs to be used to compute the address expression but then
needs to be adjusted as above. This is because only that DRs SSA names
are sure to be defined at the location we need the address.
