Re: Giving targets a say in match.pd

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.

What we have talked about, but never taken to proof of concept was the 
ability for the targets to have a rewriting pass that ran immediately 
before conversion to RTL.  The idea was to transform gimple into forms 
the target preferred and it was meant to be driven by a match.pd like 
framework.

It's not perfect, but that's the best idea in this space so far.


>
> 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.
I've argued that the multiplication form of conditional moves is bad and 
that we should canonicalize to a standard looking target = test ? 
trueval : falseval form.

What stands in the way of that is the RTL expansion path doesn't do a 
particularly good job with those forms on targets without a conditional 
move pattern.  Raphael made an attempt to fix this a year or two ago, 
but it had a few problems that needed to be sorted out.  I'd have to 
re-familiarize myself with those problems.

But obviously that's just one example.  But it shows that there is a 
path forward without breaking the core ideas behind the gimple framework.

jeff