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 = &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.
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 = &c; 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 = &c; 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 *)&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; : 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 : _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