https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #16 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #14)
> 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).
Thank you for the example. If we do the same for vector loads, that's a footgun
for users who use vector loads to access small objects:
// alignment to 16 is ensured externally
extern int a[2];
int foo()
{
a[0] = 1;
__v4si v = (__attribute__((may_alias)) __v4si *) &a;
// mask out extra elements in v and continue
...
}
This is a benign data race on data that follows 'a' in the address space, but
otherwise should be a valid and useful technique.
> 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.
But that won't fix the trapping issue? I think we need a distinct RTX for
memory accesses where hardware does fault suppression for masked-out elements.
