On Fri, May 10, 2024 at 11:06 AM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> On Fri, May 10, 2024 at 04:50:10PM +0800, HAO CHEN GUI wrote:
> > Hi Richard,
> > Thanks for your comments.
> >
> > 在 2024/5/10 15:16, Richard Biener 写道:
> > > But if targets return sth < COSTS_N_INSNS (1) but > 0 this is now no
> > > longer meaningful. So shouldn't it instead be
> > >
> > > return cost > 0 ? cost : 1;
> > Yes, it's better.
> >
> > >
> > > ? Alternatively returning fractions of COSTS_N_INSNS (1) from
> > > set_src_cost
> > > is invalid and thus the target is at fault (I do think that making zero
> > > the
> > > unknown value is quite bad since that makes it impossible to have zero
> > > as cost represented).
> > >
> > > It seems the check is to aovid pattern_cost return zero (unknown), so the
> > > comment holds to pattern_cost the same (it returns an 'int' so the better
> > > exceptional value would have been -1, avoiding the compare).
> > But sometime it adds an insn cost. If the unknown cost is -1, the total cost
> > might be distorted.
>
> *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.
Richard.
>
> Segher
