Re: Giving targets a say in match.pd

Am 08.06.26 um 11:17 schrieb Richard Biener:
> On Sat, Jun 6, 2026 at 5:02 PM Jeffrey Law via Gcc <[email protected]> wrote:
>> On 6/6/2026 6:32 AM, Georg-Johann Lay wrote:
>>> Am 06.06.26 um 00:17 schrieb Jeffrey Law:
>>>>
>>>> On 6/5/2026 3:25 AM, Georg-Johann Lay via Gcc 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.
>>>> [ ... ]
>>>> This would go against guiding principles in the gimple phases.
>>>> Essentially we very much have avoided things like target costing in
>>>> gimple.  That's part of what makes gimple transformations predictable
>>>> and relatively easy to evaluate.
>>>
>>> At no point I proposed to introduce costing.
>>>
>>> All I said is that match.pd /is/ doing "optimizations" without using
>>> any metric, which is a correct statement as far as I know.
>>>
>>> And without a metric, you have no idea where you are heading.
>>> That works for trivial cases like x * 0 = 0, and when all the
>>> dozens of targets behave similar in this regard.
>>>
>>> There are cases though where different targets means different metrics.
>> You may not not explicitly mentioned costing, but the net effect is the
>> same -- the targets end up making arbitrary changes to the gimple IL and
>> that's what we've fundamentally wanted to avoid since the initial
>> development of the tree-ssa work.
> 
> The motivation for this is to be able to apply test coverage for target X also
> to target Y, at least for the GIMPLE side of things.

Okay, thanks for the context.  Though that's not working out very well
for avr. There are many failing tree-ssa test cases.  And it's not even
clear what the tests are expecting in the case of avr.

> For some of the problematic patterns it is probably worth considering that
> they are really RTL expansion helpers and thus inherently target specific.
> There's now fold_before_rtl_expansion_p () as a way to defer a folding
> as much as possible, it's uses might not match a classification as
> "for-RTL-expansion" though and we're not applying them at ISEL time
> (and there there's limited target control as well).
> 
> For AVR one issue it faces is there's only yes or no to providing
> named patterns for things like addsi3 and mulsi3 and both come
> with downsides.  Meaning the usual middle-end way of querying
> whether a target can do sth is unhelpful.
> 
> Richard.

Indeed.  Just the fact that some standard insn exists doesn't mean at
all that it's cheap.  It just means that the code generation is better
than without the insn -- which is useless for costing, so cost
estimators shouldn't make such assumptions.

Johann