Re: [PATCH][RFC] middle-end/110237 - wrong MEM_ATTRs for partial loads/stores

[Jeff Law <jeffreyalaw@gmail.com>]

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