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
