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). Richard. > > IMO calling insn_cost on a non recognized (aka possibly unrecognizable) > > insn doesn't make much sense. > > Calling insn_cost on something that is not an insn makes no sense, yeah. > > > Segher > -- 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)
