On Wed, 22 Jul 2026, Jeffrey Law wrote: > > > On 7/22/2026 7:32 AM, Richard Biener wrote: > > On Wed, 22 Jul 2026, [email protected] wrote: > > > >> Hi! > >> > >> On Tue, Jul 21, 2026 at 04:34:44PM +0200, Richard Biener wrote: > >>> The following makes the recognized INSN_CODEs available to the > >>> backends for costing via insn_cost. > >> Why would you want to do this? This is redundant information. > >> > >> If some backend finds things too slow, it can implement some cache > >> itself, that will speed things up much more, anyway. > >> > >> Why would a backend want an insn_code in the first place, to calculate > >> costs? Something smells here. > > Because the backend then can use get_attr_type (..) for classification > > for example. Without INSN_CODE all the meta-info attached to patterns > > isn't accessible without calling recog itself (redundantly so, in the > > case of combine). > 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. The point about get_attr_length is valid, adding a "speed_cost" attribute to the machine description, even if it just is an enum you dispatch through uarch cost tables, would be an improvement as well. 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. Richard. > Jeff > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Abhinav Puri; (HRB 36809, AG Nuernberg)
