https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #12 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 #11 from Alexander Monakov <amonakov at gcc dot gnu.org> --- > The trapping angle seems valid, but I have a really hard time understanding > the > DSE issue, and the preceding issue about disambiguation based on RTL aliasing. > > How would DSE optimize out 'd[5] = 1' in your example when the mask_store > reads > it? Isn't that a data dependency? Ah, yes - I completely missed that. > How is the initial issue different from > > int f(__m128i *p, __m128i v, int *q) > { > *q = 0; > *p = v; > return *q; > } > > that we cannot optimize to 'return 0' due to __attribute__((may_alias)) > attached to __m128i? 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. I've proposed a patch for that issue at hand (clear MEM_EXPR for all partial load/store MEMs), but didn't yet get an approval. The question of what RTL analysis can derive from the RTL is also still open (but it might be we're "safe" because it just doesn't do any analysis/transform that would be mislead)
