Re: Giving targets a say in match.pd

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
>