Hi! On Fri, May 10, 2024 at 09:16:26AM +0200, Richard Biener wrote: > On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI <guih...@linux.ibm.com> wrote: > > But if set_src_cost returns a value less than COSTS_N_INSNS (1), it's > > untouched and just returned by pattern_cost. Thus "zero" from set_src_cost > > is higher than "one" from set_src_cost. > > > > For instance, i386 returns cost "one" for zero_extend op. > > //ix86_rtx_costs > > case ZERO_EXTEND: > > /* The zero extensions is often completely free on x86_64, so make > > it as cheap as possible. */ > > if (TARGET_64BIT && mode == DImode > > && GET_MODE (XEXP (x, 0)) == SImode) > > *total = 1; > > > > This patch fixes the problem by converting all costs which are less than > > COSTS_N_INSNS (1) to COSTS_N_INSNS (1). > > > > Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no > > regressions. Is it OK for the trunk? > > 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;
I don't think either is very good. Why does it want to convert "unknown cost" to some known cost at all? Fixing *that* would really improve things! > ? 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). No, we have COST_N_INSNS exactly because fractions of integer costs are useful to have. COST_N_INSNS (1) really stands for "the cost of a cheap integer isns with latency 1", and many targets want to express some insns are better than others, even if they have the same latency. Perhaps some insns use less of some resource, etc. > 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). Cost 0 for unkown is used in (almost) *all* cost things in RTL. Pretty much everything can deal with it just fine. What is different here? The abstraction "pattern_cost" is a lousy abstraction of course, but where is this used? Cost "unknown" can be passed through everywhere, in principle. Segher
