On May 8, 2020 10:57:35 PM GMT+02:00, Alexandre Oliva <ol...@adacore.com> wrote:
>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?
Both use availability and should never replace with a later definition. The
issue is when you mix availability data from both, which might differ, you can
run into this behavior.
Maybe I should experiment with removal of this dual implentation... (I kept it
for compile time reasons, but there without doing any measurements).
Richard.
>
>Thanks in advance,
