On Fri, May 10, 2024 at 12:54 PM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> On Fri, May 10, 2024 at 12:19:35PM +0200, Richard Biener wrote:
> > On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
> > <seg...@kernel.crashing.org> wrote:
> > > *All* code using a cost will have to be inspected and possibly adjusted
> > > if you decide to use a different value for "unknown" than what we have
> > > had for ages. All other cost functions interacting with this one, too.
> >
> > Btw, looking around pattern_cost is the only API documenting this special
> > value and the function after it using this function, insn_cost does the same
> > but
> >
> > int
> > insn_cost (rtx_insn *insn, bool speed)
> > {
> > if (targetm.insn_cost)
> > return targetm.insn_cost (insn, speed);
> >
> > and the target hook doesn't document this special value. set_src_cost
> > doesn't either, btw (that just uses rtx_cost). So I don't think how
> > pattern_cost handles the set_src_cost result is warranted. There's
> > simply no way to detect whether set_src_cost returns an actual
> > value - on the contrary, it always does.
>
> I introduced insn_cost. I didn't think about documenting that 0 means
> unknown, precisely because that is so pervasive!
But for example a reg-reg move when optimizing for speed could have
a zero associated cost. You might argue that's a bug since there's
an actual instruction and thus at least a size cost (and decode cost)
but then I've seen too much zero cost stuff in backends (like that
combine PR causing s390 backend making address-cost zero even
though it's just "same cost").
IMO give we're dispatching to the rtx_cost hook eventually it needs
documenting there or alternatively catching zero and adjusting its
result there. Of course cost == 0 ? 1 : cost is wrong as it makes
zero vs. one the same cost - using cost + 1 when from rtx_cost
might be more correct, at least preserving relative costs.
Richard.
>
>
> Segher
