On Fri, Jun 5, 2026 at 2:25 AM Georg-Johann Lay via Gcc <[email protected]> wrote: > > 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 */
The simple answer here is expand should see if `((typeof(y))zero_one * z)` is cheaper than `(zero_one) ? z : 0`. I have some ideas on implementing that but I have not got around to it yet. > > 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 >
