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