Richard Biener <rguent...@suse.de> writes: > I'm facing the issue that we have vector type dependent information > stored in dr_vec_info (the misalignment at least) and that with > BB vectorization (at least) we want to be able to access a DR group with > two different vector types. > > I've run into this with > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547981.html and > created the testcase > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547987.html > in response to the fallout. > > I'm thinking of ways to circumvent this issue. In the end when > we're SLP only my idea was that the stmt_vec_info (and thus the > embedded dr_vec_info) only contain data that is valid in all > possible SLP contexts. While we still have both SLP and non-SLP > paths the approach of duplicating things on the SLP node becomes > too complicated in most cases. So one possible "fix" is to put > conservative values in dr_vec_info - for the misalignment this > means consider the values of the vector type with the largest > target alignment. Another possible fix is to not store anything > vector type dependent there but compute such info in the places > where we need it which then need to pass the actual vector type > used.
It looks like all the information except for: /* The data reference itself. */ data_reference *dr; /* The statement that contains the data reference. */ stmt_vec_info stmt; is really per-vector-stmt(-group) rather than per-scalar-stmt. And “stmt” is really just there to provide a cheaper alternative to a lookup_stmt on the DR_STMT. So in an all-SLP world, it looks like the whole of dr_vec_info should be per SLP node rather than per stmt_vec_info (possibly without the “stmt” field if it isn't useful then). During the transition period, could we store the dr_vec_infos separately from the stmt_vec_infos, and just have pointers to them in the stmt_vec_info instead? Then we could do the usual “if slp_node is nonnull, get the information from there, otherwise get it from stmt_info“ routine. Maybe it would be worth having an SLP node pointer in the dr_vec_info for reverse lookups? Probably none of that was helpful, sorry… Richard
