bug in DSE?

bug in DSE?

[Andrew MacLeod]

I dont't want to immediately open a PR,  so I'll just ask about 
testsuite/gcc.dg/pr83609.c.

the compilation string  is
   -O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre -fno-tree-pre 
-fno-code-hoisting

Which passes as is.

if I however add   -fno-tree-vrp   as well, then it looks like dead 
store maybe does something wong...

with EVRP running, we translate function foo() from


complex float foo ()
{
   complex float c;
   complex float * c.0_1;
   complex float _4;

   <bb 2> :
   c.0_1 = &c;
   MEM[(long long unsigned int *)c.0_1] = 1311768467463790320;
   _4 = c;
   c ={v} {CLOBBER};
   return _4;

}
to

   complex float c;
   complex float _4;

   <bb 2> :
   MEM[(long long unsigned int *)&c] = 1311768467463790320;
   _4 = c;
   c ={v} {CLOBBER};
   return _4;

and everything works fine.

If we don't do EVRP, then DSE takes the original, and reports:

   Deleted dead store: MEM[(long long unsigned int *)c.0_1] = 
1311768467463790320;

transforming it to:

complex float foo ()
{
   complex float c;
   complex float * c.0_1;
   complex float _4;

   <bb 2> :
   c.0_1 = &c;
   _4 = c;
   c ={v} {CLOBBER};
   return _4;

}

That doesn't seem right?

and the place where it is inlined in main() becomes
  <bb 2> :
   _4 = c_11(D);
   _10 = _4;
   _1 = _10;
   u$c_9 = _1;
   _2 = VIEW_CONVERT_EXPR<long long unsigned int>(u$c_9);
   if (_2 != 1311768467463790320)


I not really sure exactly what is going on...  but I do know that the 
testcase aborts() if we turn off VRP :-P

Andrew

Re: bug in DSE?

[Marc Glisse]

On Fri, 12 Feb 2021, Andrew MacLeod via Gcc wrote:

> I dont't want to immediately open a PR,  so I'll just ask about 
> testsuite/gcc.dg/pr83609.c.
>
> the compilation string  is
>   -O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre -fno-tree-pre 
> -fno-code-hoisting
>
> Which passes as is.
>
> if I however add   -fno-tree-vrp   as well, then it looks like dead store 
> maybe does something wong...
>
> with EVRP running, we translate function foo() from
>
>
> complex float foo ()
> {
>   complex float c;
>   complex float * c.0_1;
>   complex float _4;
>
>   <bb 2> :
>   c.0_1 = &c;
>   MEM[(long long unsigned int *)c.0_1] = 1311768467463790320;
>   _4 = c;

Isn't that a clear violation of strict aliasing?

-- 
Marc Glisse

Re: bug in DSE?

[Richard Biener]

On February 13, 2021 12:20:48 AM GMT+01:00, Marc Glisse <marc.glisse@inria.fr> wrote:
>On Fri, 12 Feb 2021, Andrew MacLeod via Gcc wrote:
>
>> I dont't want to immediately open a PR,  so I'll just ask about 
>> testsuite/gcc.dg/pr83609.c.
>>
>> the compilation string  is
>>   -O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre -fno-tree-pre 
>> -fno-code-hoisting
>>
>> Which passes as is.
>>
>> if I however add   -fno-tree-vrp   as well, then it looks like dead
>store 
>> maybe does something wong...
>>
>> with EVRP running, we translate function foo() from
>>
>>
>> complex float foo ()
>> {
>>   complex float c;
>>   complex float * c.0_1;
>>   complex float _4;
>>
>>   <bb 2> :
>>   c.0_1 = &c;
>>   MEM[(long long unsigned int *)c.0_1] = 1311768467463790320;
>>   _4 = c;
>
>Isn't that a clear violation of strict aliasing?

Yes. We try DWIM if we see the must-alias though. Please see what the testcase was added for and eventually consider adding -fno-strict-aliasing.