On May 8, 2020, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> OK, so I think the issue is that we are using RPO availability during
> the DOM elimination walk at all - there can be easily disconnects
> between what RPO iteration left us with and what the DOM walk
> eliminates. Fixing this fixes the testcase.
> There's also the missed optimization of not figuring &(*_41)[0]{lb: _46 sz:
> 16};
> is simply _41 during valueization and forwarding of the address. I
> have a fix for that as well and that also fixes the issue independently
> on the above fix.
Cool!, two fixes in one! :-)
Thanks for looking into it, and for the patch.
I'm still a little concerned that other circumstances that still use
rpo_vn_valueize might run into such loops as the one I've seen.
AFAICT the specific situation that failed won't any more, not just
because of the improved forward propagation, but also because the
eliminate_dom_walker always seems to eliminate SSA_NAMEs in favor of
earlier definitions, so there's no risk of an infinite loop there.
However, it appears that rpo_vn_valueize might still replace a SSA_NAME
with a later definition, that could bring us back to the one just
eliminated. Do you by any chance have a simple argument to rule out
this possibility?
Thanks in advance,
--
Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo/
Free Software Evangelist Stallman was right, but he's left :(
GNU Toolchain Engineer Live long and free, and prosper ethically
