https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 26 Jun 2023, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237 > > --- Comment #13 from Alexander Monakov <amonakov at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #12) > > As explained in comment#3 the issue is related to the tree alias oracle > > part that gets invoked on the MEM_EXPR for the load where there is > > no information that the load could be partial so it gets disambiguated > > against a decl that's off less size than the full vector. > > With my example I'm trying to say that types in the IR are wrong if we > disambiguate like that. People writing C need to attach may_alias to vector > types for plain load/stores to validly overlap with scalar accesses, and when > vectorizer introduces vector accesses it needs to do something like that, or > else intermixed scalar accesses may be incorrectly disambiguated against new > vector ones. vectors of T and scalar T interoperate TBAA wise. What we disambiguate is int a[2]; int foo(int *p) { a[0] = 1; *(v4si *)p = {0,0,0,0}; return a[0]; } because the V4SI vector store is too large for the a[] object. That doesn't even use TBAA (it works with -fno-strict-aliasing just fine). If the v4si store is masked we cannot do this anymore, but the IL we seed the alias oracle with doesn't know the store is partial. The only way to "fix" it is to take away all of the information from it.
