Re: Giving targets a say in match.pd

Am 05.06.26 um 13:55 schrieb Richard Biener:
> On Fri, Jun 5, 2026 at 12:53 PM Georg-Johann Lay via Gcc
> <[email protected]> wrote:
>>
>> Am 05.06.26 um 11:41 schrieb Andrew Pinski:
>>> 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's already a bad proxy because `(zero_one == 0) ? y : z <op> y`
>> my be cheaper (an actually is on avr) than `(zero_one) ? z : 0`.
>>
>> Moreover, the multiplication in the mentioned form may no survive
>> until expand, e.g. may have been transformed to something different
>> when the code is more complex than a minimal example.
> 
> In this case gating the transform on TYPE_PRECISION (type) <=
> GET_MODE_PRECISION (word_mode)
> would work?  To the extent still leaving AVR with a 8 bit multiply instead of
> a test-and-branch.

It would improve the situation as a side effect.  IMHO such a condition
is not the right thing to do and is unrelated to the root cause. Plus,
on targets that are not plagued by this, it might introduce a missed
optimization.

> In general I agree with Andrew that match.pd, for this kind of "optimizations",
> needs to apply costing.

As far as I understand, that approach works at tree -> rtl lowering when
rtx costs are available.  IIUC there's nothing like costs at match.pd time.

> I'll note that this pattern attempts at if-converting
> code which can expose the code to additional optimization which you might
> lose when not applying if-conversion, so it's not always black-or-white and
> costing just a single transform can miss a bigger picture.

Additional transformations / optimizations makes the problem even worse,
because patterns that try to roll back bad optimizations — be it at
expand time or combine time — won't match any more.

>>>> 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.
> 
> That's an interesting idea.  To be practical w/o changs the target.pd would
> need to be included first and would need to "succeed" in transforming.  So
> I'm not sure this is very maintainable - also considering that match.pd might
> change slightly and the target.pd no longer matching.
> 
> I actually do consider a target.pd useful, but limited to pre-RTL-expansiion
> and to add additional patterns, not disable others.
> 
>>>>
>>>> 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