In match.pd there are two kinds of patterns: Canonicalizations and optimizations.
While canonicalizations simplify the compile task by reducing combinatorial complexity, optimization patterns try to improve code performance. The trouble with the optimization patterns is that they operate blindly, not considering costs or target capabilities in any way. Particularly bad example are patterns of the form /* (zero_one == 0) ? y : z <op> y -> ((typeof(y))zero_one * z) <op> y */ /* (zero_one != 0) ? z <op> y : y -> ((typeof(y))zero_one * z) <op> y */ that map single-bit tests to multiplications, even on machines where multiplication is very expensive, and even when a target doesn't support multiplications. All a back end can do is try to write patterns for the insn combiner and such, that try to undo code that makes GCC look stupid and ridiculous. In cases where MUL is expanded to a libcall, rolling back is not even possible. So the question is: Is possible and wanted to give targets a say in whether match.pd patterns should be rejected? The next question is how this could be implemented? Here is a proposal: Support a file like <target>.pd in the back end, that, if present, takes precedence over the middle end's match.pd. That way, a backend could reject / FAIL patterns like the ones above. The advantages are: * There's already support to generate .cc from .pd. * No cluttering up of match.pd of any kind. * No need for complicated C code that evaluates trees or RTXes like in rtx costs. As a final note: Using the existence of a standard insn as a proxy would be a bad choice. Existence of say, mulsi3, doesn't mean at all that such a pattern is cheap in any way. Thanks, Johann
