https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On October 7, 2020 5:30:14 PM GMT+02:00, "jakub at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307 > >Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |jakub at gcc dot gnu.org > >--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- >(In reply to Richard Biener from comment #3) >> The patch will cause >> >> FAIL: gcc.dg/vect/pr65947-3.c scan-tree-dump-times vect "LOOP >VECTORIZED" 2 >> >> since the testcase has exactly such a pattern: >> >> unsigned int >> condition_reduction (unsigned int *a, unsigned int min_v, unsigned >int *b) >> { >> unsigned int last = N + 65; >> unsigned int aval; >> >> for (unsigned int i = 0; i < N; i++) >> { >> aval = a[i]; >> if (b[i] < min_v) >> last = aval; >> } >> return last; >> } >> >> and sinking the aval = a[i] load causes if-conversion to no longer >happen >> because a[i] now appears to only conditionally trap. It will be >vectorized >> with masked loads if those are available though, so I'm considering >to >> XFAIL it for the moment. > >Isn't that an important real-world case though? I mean, people who >care a lot >about the vectorization often change code from the loads in the >conditionals to >preloading the value before the condition, such that it can be >vectorized and >now it won't (and masked loads are less common among architectures that >can >vectorize such loops than non-masked ones). >So shouldn't we just sink that way calls before vectorization and after >vectorization everything? Or have some way to tell ifcvt it can undo >the >sinking. It is a general issue we might want to address. Either by if converting this earlier (phiopt, had some patches with the min/max stuff I dropped the ball on) or by doing sinking only after loop opts /vectorization (like we moved predcom). That we didn't sink here is an artifact of the testcase surroundings, not the actual kernel.
