This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Share dataref and data dependence analysis for multi-vector size processing


Richard Biener <rguenther@suse.de> writes:
> The following is an (incomplete) attempt at making the vectorizer
> share dataref and dependence analysis for loop vectorization when
> analyzing the loop for multiple vector sizes.
>
> A prerequesite for sharing the datarefs and dependence relations
> is that they are not changed during the analysis phases but only
> possibly during transform.
>
> For this to work parts depending on the vector size need to be moved
> away from the dataref structure - fortunately that's only what
> the vectorizer puts in dr->aux, namely for example the desired
> alignment.  I've put that into the stmt_info instead of into
> dr->aux in the following patch.
>
> I have added verifying that the dataref structures do not change
> and that expectedly fails currently for the gather/scatter and
> simdlane "hacks" in vect_analyze_data_refs.  I'm trying to re-organize
> those now but it's a slow process so I'm seeking feedback on this
> in its current state.
>
> I've concentrated on loop vectorization, for BB vectorization
> iterating over vector sizes might not make so much sense in the end
> but sharing datarefs should be possible there as well (we don't
> compute dependences in the same way so the savings are less).
>
> So the main parts of the patch are moving away from using dr->aux
> plus introducing a new vec_info_shared object that is kept for
> multiple vec_info instances.
>
> I need to work on the simd/gather/scatter issue and hopefully
> that will be cleaned up as a pre-patch.
>
> So - comments?  Ideas?

Looks like a nice cleanup.

Maybe not directly related, but since I just noticed it the other day:
I think we're too eager to classify !vect_analyze_data_ref_accesses
as a "fatal" failure, since it's possible for a group of stores to be a
gapped group with one vector size and an SLP-able group with a smaller
vector size.  So maybe that function needs to be split up into things
that can be done on the shared structure and things that are done
per vector size, with the latter not being fatal?

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]