This is the mail archive of the
mailing list for the GCC project.
Re: [patch] RFC: Hook for insn costs?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 17 Jul 2017 06:07:29 -0500
- Subject: Re: [patch] RFC: Hook for insn costs?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20170715225119.GA13471@gate.crashing.org> <CAFiYyc21ALx=eSbOUMNo+B-MqMutVRgUfkpmi_7v1KkNs4kF3A@mail.gmail.com>
On Mon, Jul 17, 2017 at 12:20:16PM +0200, Richard Biener wrote:
> > So I argue that we want to have a hook for insn cost.
> And I think at previous GNU Cauldrons we agreed to that.
Excellent! So now it just needs to happen ;-)
> > 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 ...
> > And if an rtx_insn, should that than be an
> > rtx_insn that is already linked into the insn chain (so we can see what
> > other insns generate its inputs, and which of its outputs are unused,
> > etc.)?
I think you need an insn for the dataflow things. But, not all callers
can use that I suppose (combine can -- although combine currently does
not keep useful DF info). I guess we should start with just pattern_cost.