On 11/27/23 05:39, Robin Dapp wrote:
The easiest way to avoid running into the alias analysis problem is
to scrap the MEM_EXPR when we expand the internal functions for
partial loads/stores. That avoids the disambiguation we run into
which is realizing that we store to an object of less size as
the size of the mode we appear to store.
After the patch we see just
[1 S64 A32]
so we preserve the alias set, the alignment and the size (the size
is redundant if the MEM insn't BLKmode). That's still not good
in case the RTL alias oracle would implement the same
disambiguation but it fends off the gimple one.
This fixes gcc.dg/torture/pr58955-2.c when built with AVX512
and --param=vect-partial-vector-usage=1.
On riscv we're seeing a similar problem across the testsuite
and several execution failures as a result. In the case I
looked at we move a scalar load upwards over a partial store
that aliases the load.
I independently arrived at the spot mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237#c4
before knowing about the PR.
I can confirm that your RFC patch fixes at least two of the
failures, I haven't checked the others but very likely
they are similar.
FWIW, it should always be safe to ignore the memory attributes. So if
there's a reasonable condition here, then we can use it and just ignore
the attribute.
Does the attribute on a partial load/store indicate the potential
load/store size or does it indicate the actual known load/store size.
If the former, then we probably need to treat it as a may-read/may-write
kind of reference.
Jeff
