Re: bug in DSE?
On February 13, 2021 12:20:48 AM GMT+01:00, Marc Glisse
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;
>>
>> :
>> c.0_1 =
>> 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.
Re: bug in DSE?
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;
:
c.0_1 =
MEM[(long long unsigned int *)c.0_1] = 1311768467463790320;
_4 = c;
Isn't that a clear violation of strict aliasing?
--
Marc Glisse
bug in DSE?
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;
:
c.0_1 =
MEM[(long long unsigned int *)c.0_1] = 1311768467463790320;
_4 = c;
c ={v} {CLOBBER};
return _4;
}
to
complex float c;
complex float _4;
:
MEM[(long long unsigned int *)] = 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;
:
c.0_1 =
_4 = c;
c ={v} {CLOBBER};
return _4;
}
That doesn't seem right?
and the place where it is inlined in main() becomes
:
_4 = c_11(D);
_10 = _4;
_1 = _10;
u$c_9 = _1;
_2 = VIEW_CONVERT_EXPR(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
