https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
--- Comment #8 from Jeffrey A. Law <law at gcc dot gnu.org> --- So I was playing with the patch Raphael and I put together a bit more. A few things to note. First, if we're going to use the match.pd bits in some way, they need to be conditional on GIMPLE. If used on generic trees it can eliminate an argument with side effects, a definite no-no. It didn't even occur to me to worry about that in this context. While we could perhaps use omit_one_operand, there may be a better path forward... Second, with the match.pd suitably restricted it still causes headaches with things like MIN/MAX recognition. Presumably there's either other match.pd patterns or something else that knows how to identify those [0,1] * x sequences when they show up for nontrivial synthesis of MIN/MAX. By simplifying to a conditional move we're not picking up MIN/MAX as often as we should. Raphael's work on the expander was far simpler than I expected it to be. The basic idea was to provide a fallback path to the old expansion code for targets that didn't support conditional moves so that if we recognized more conditional moves in gimple we didn't regress such targets. But if we're not going to try and use something like the match.pd patch, then that hunk isn't particularly useful. But reviewing that hunk made me realize that we did have the right bits in place to test for 0/1 values during expansion. So instead of recognizing the multiplication as a conditional move, we could just recognize the multiplication pattern during expansion and potentially generate a conditional move. That seems to be working much better. We're generating better code for pr114277, pr111126, and pr118384 without the undesirable side effects of my original approach. At least on simple tests. Larger tests are in flight. T
