On 08/02/2017 01:34 PM, Richard Earnshaw wrote: > On 26/07/17 18:54, Jeff Law wrote: >> On 07/17/2017 02:35 PM, Richard Henderson wrote: >>> On 07/17/2017 12:20 AM, Richard Biener wrote: >>>> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool >>>>> Now what should it take as input? An rtx_insn, or just the pattern >>>>> (as insn_rtx_cost does)? >>>> >>>> Is there any useful info on the other operands of an rtx_insn? If not >>>> then passing in the pattern (a rtx) might be somewhat more flexible. >>>> Of course it's then way easier to confuse rtx_cost and insn_cost ... >>> >>> A lot of really complex by-hand pattern matching goes away if you know >>> the instruction is valid, and you can look up an insn attribute. That >>> suggests passing the insn and not the PATTERN. >> Good point. In fact, it opens the possibility that costing could be >> attached to the insn itself as just another attribute if it made sense >> for the target to describe costing in that manner. >> >> Jeff >> > > I'm not sure if that's a good or a bad thing. I haven't really though much about it and I certainly wouldn't push for it as a direction without further investigation. It's just one thing that could be possible if we though it made sense.
jeff
