On 08/23/2017 04:37 AM, Richard Biener wrote: > On Tue, Aug 22, 2017 at 5:13 PM, Jeff Law <l...@redhat.com> wrote: >> However, there are still cases where we have a conditional equivalence >> and the names have the same cost to compute. A greatly simplified >> example can be found in gcc.dg/tree-ssa/20030922-2.c. > > So the intent is (as in the patch) to not record any conditional equivalence > for this case? Correct. We're no longer recording these conditional equivalences in the const/copies table and SSA_NAME_VALUE. The only time we will record them now is if one name is cheaper to compute than the other (so that we can potentially propagate away the expensive one).
Note that we still have 1 = NAME1 eq NAME2 In the expression hash table, which is what allows us to still simplify stuff like NAME1 ^ NAME2 -> 0 and the like. The mechanism by which that gets simplified now is different, hence the change in dump scanning. But to reiterate, we're no longer recording the conditional equivalences into the const/copies table by default and thus we no longer use conditional equivalences for const/copy propagation by default. > >> I've simply xfailed this test. To fix it we need to build a second set >> of tables that are essentially the conditional equivalences, without >> setting SSA_NAME_VALUE (SSA_NAME_VALUE is what drives const/copy >> propagation in DOM). That's actually fairly easy and not terribly >> costly. What gets ugly is we have to consult this second set of tables >> when doing simplifications. Worse yet, we have to run through each >> operand's conditional equivalences, substitute it in and try to >> simplify. It just don't expect it to hit enough to justify that pain. > > Agreed. Note I think the main issue is that conditional equivalences > do not play well with value-numbering as they affect values of already > visited expressions. So you'd basically have to re-iterate value-numbering > possibly affected expressions (recording the new result only temporarily > of course). Understood. I still want to flesh out the unwindable equivalence classes a bit further so I can measure how often cases like 20030922-2.c occur in practice. My sense is there's still some cases we're going to want to handle, but I'm going to have to build the fully generalized version to get enough instrumentation to guide that decision. > >> The net result is we should stop ping-ponging copy propagations that >> arise from conditional equivalences at the loss of some minor >> optimizations in code similar to 20030922-2.c. > > Can you file a PR for the XFAIL? Will do. > >> Bootstrapped and regression tested on x86_64. Installing on the trunk. > > Thanks for finally taking a stab at this. It's been on my list for a while :-) Jeff
