This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][vect] Keep track of DR_OFFSET advance in dr_vec_info rather than data_reference
- From: Richard Biener <rguenther at suse dot de>
- To: "Andre Vieira (lists)" <andre dot simoesdiasvieira at arm dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at arm dot com
- Date: Wed, 8 Jan 2020 08:38:18 +0100 (CET)
- Subject: Re: [PATCH][vect] Keep track of DR_OFFSET advance in dr_vec_info rather than data_reference
- References: <7bff5728-7991-80fc-d630-1e344f810699@arm.com> <43440f2d-b447-a73a-1f91-1fd1a82e2694@arm.com>
On Tue, 7 Jan 2020, Andre Vieira (lists) wrote:
> Hello,
>
> Should we try to get this refactoring in stage 3 or park it for next stage 1?
I only looked at the patch now and I think it nicely simplifies things.
The patch is OK now with the usual function comment added before
}
+inline tree
+get_dr_vinfo_offset (dr_vec_info *dr_info, bool check_outer = false)
+{
+ innermost_loop_behavior *base;
Thanks,
Richard.
> Cheers,
> Andre
>
> On 10/12/2019 13:36, Andre Vieira (lists) wrote:
> > Hi,
> >
> > This patch aims at refactoring the vectorizer code to no longer need to
> > reset DR_OFFSET for epilogue vectorization and instead keep track of
> > DR_OFFSET changes per dr_vec_info and just update it as needed. I added a
> > member of type 'tree' called 'offset' to dr_vec_info, which keeps track of
> > the changes to the data_reference's offset per dr_vec_info and thus per
> > instance of loop vectorization. To get the current loop's DR_OFFSET I
> > introduced a function 'get_dr_vinfo_offset' which will add the dr_vec_info's
> > offset to either the data_reference's innermost offset or the offset of the
> > 'innermost_loop_behavior' returned by 'vect_dr_behavior' depending on
> > whether 'get_dr_vinfo_offset's second parameter 'check_outer' is true. This
> > is to mimic the behavior of using the outer loop relative
> > 'innermost_loop_behavior' in 'vect_create_addr_base_for_vector_ref'.
> >
> > I regression tested vect.exp on aarch64 and x86_64. I also regression tested
> > libgomp on aarch64 and x86_64, no changes, but there were quite a few test
> > failures with the commit I based this patch on...
> >
> > Is this OK for trunk or shall I wait until libgomp stabilizes?
> >
> > 2019-12-10 Andre Vieira <andre.simoesdiasvieira@arm.com>
> >
> > * tree-vect-data-refs.c (vect_create_addr_base_for_vector_ref): Use
> > get_dr_vinfo_offset
> > * tree-vect-loop.c (update_epilogue_loop_vinfo): Remove
> > orig_drs_init
> > parameter and its use to reset DR_OFFSET's.
> > (vect_transform_loop): Remove orig_drs_init argument.
> > * tree-vect-loop-manip.c (vect_update_init_of_dr): Update the
> > offset
> > member of dr_vec_info rather than the offset of the associated
> > data_reference's innermost_loop_behavior.
> > (vect_update_init_of_dr): Pass dr_vec_info instead of
> > data_reference.
> > (vect_do_peeling): Remove orig_drs_init parameter and its
> > construction.
> > * tree-vect-stmts.c (check_scan_store): Replace use of DR_OFFSET
> > with get_dr_vinfo_offset.
> > (vectorizable_store): Likewise.
> > (vectorizable_load): Likewise.
>
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)