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. 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. > > Jeff >
