Need sanity check on DSE vs expander issue

[Richard Biener]

On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>I need a sanity check here.
>
>Given this code:
>
>> typedef union { long double value; unsigned int word[4]; }
>memory_long_double;
>> static unsigned int ored_words[4];
>> static void add_to_ored_words (long double x)
>> {
>>   memory_long_double m;
>>   size_t i;
>>   memset (&m, 0, sizeof (m));
>>   m.value = x;
>>   for (i = 0; i < 4; i++)
>>     {
>>       ored_words[i] |= m.word[i];
>>     }
>> }
>> 
>
>DSE is removing the memset as it thinks the assignment to m.value is
>going to set the entire union.
>
>But when we translate that into RTL we use XFmode:
>
>> ;; m.value ={v} x_6(D);
>> 
>> (insn 7 6 0 (set (mem/v/j/c:XF (plus:DI (reg/f:DI 77
>virtual-stack-vars)
>>                 (const_int -16 [0xfffffffffffffff0])) [2 m.value+0
>S16 A128])
>>         (reg/v:XF 86 [ x ])) "j.c":13:11 -1
>>      (nil))
>> 
>
>That (of course) only writes 80 bits of data because of XFmode, leaving
>48 bits uninitialized.  We then read those bits, or-ing the
>uninitialized data into ored_words and all hell breaks loose later.
>
>Am I losing my mind?  ISTM that dse and the expander have to agree on
>how much data is written by the store to m.value.

It looks like MEM_SIZE is wrong here, so you need to figure how we arrive at this (I guess TYPE_SIZE vs. MODE_SIZE mismatch is biting us here?)

That is, either the MEM should have BLKmode or the mode size should match
MEM_SIZE. Maybe DSE can avoid looking at MEM_SIZE for non-BLKmode MEMs? 

Richard. 

>
>Jeff