Hi! On Sat, Apr 04, 2020 at 10:21:00AM +1030, Alan Modra wrote: > I have a series of small patches already, the most significant so far > being the one that adds the following comment to rs6000_rtx_costs: > > "Calls from places like optabs.c:avoid_expensive_constant will come > here with OUTER_CODE set to an operation such as AND with X being a > CONST_INT or other CONSTANT_P type. This will be compared against > set_src_cost, where we'll come here with OUTER_CODE as SET and X > the same constant. > > Calls from places like default_noce_conversion_profitable_p will > come here via seq_cost and pass the pattern of a SET insn in X.
That uses set_rtx_cost, which still doesn't use insn_cost, yes. set_rtx_cost and set_src_cost are the two biggest things that still need rtx_cost. > The SET isn't handled here so *TOTAL will remain as > COSTS_N_INSNS(1) multiplied by the number of words being set. > Presuming the insn is valid and set_dest a reg, rs6000_rtx_costs > will next see the set_src. Continuing the example of an AND, this > might be an AND of two other regs. This AND should cost zero here > since the insn cost has already been counted. The overall cost > value should be comparable to rs6000_insn_cost." The biggest problem in converting it is that sometimes there is no valid code yet, and constructing it isn't easy either, but some code still wants to know the cost :-/ > It pays to figure out what you need to do before doing anything. :-) Yes :-) > Those two paragraphs will result in quite a few changes. The first > one means that, for example, the rs6000_is_valid_and_mask test belongs > under case CONST_INT as > || (outer_code == AND > && rs6000_is_valid_and_mask (x, mode)) > not under case AND. Does it? Isn't the rtx_cost logic inside-out enough already? > The second paragraph says we are costing practically all operations > too highly. Another huge advantage of insn_cost. > I'm still in analysis mode, worried about whether gcc generates deep > rtl expressions to pass to rtx_cost. Yes :-( > I have a vague recollection of > seeing that years ago, but it looks like most places with anything > complex generate a sequence of insns and cost the sequence. Sure, and anything not a single_set will use insn_cost, not set_rtx_cost, and sanity prevails. > If we do > have expressions like (set (reg1) (and (plus (reg2) cst1) cst2)) then > rs6000_rtx_cost should recognise that AND as costing an extra insn. Well, what does such an expression *mean*, if there is no instruction like that? How should we estimate the cost if we do not know what insns it will generate? Segher
