On 7/22/2026 8:00 AM, Richard Biener wrote:
On Wed, 22 Jul 2026, Jeffrey Law wrote:
It's not common, but I think I've seen this kind of behavior in targets. For
example, they may try to get at an insn's length as that may be the main
driver for costing. Obviously this doesn't work when called for an RTL
fragment vs a real insn.
So to me the core question is should combine present the target with
recognized insns when possible or should the target be defensive and force
recognition when it wants to look at insn attributes. I don't necessarily
think this has to be an either-or answer. It could be yes to both.
If the information is readily available, as it seems for combine, it
seems odd to withhold it. Sure, the target might be forced to
recompute - but then why use insn_cost on something that you'll have
to throw away? It looks like you instead wanted to use rtx_cost there,
or pattern_cost.
Yea, in the case where it's readily available, withholding seems
counter-productive (as is the case here).
That said, x86 maintainers requested that over adding manual
pattern matching in the insn_cost hook. Calling recog () there
feels redundant if the info is already there.
Yea, makes sense to me as well.
Given Segher has some concerns, let's give him the opportunity to chime
back in. So let go with OK unless someone objects by Friday your time.
Jeff
