On Wed, Feb 23, 2022 at 07:32:55PM +0800, guojiufu wrote: > >We already have TARGET_INSN_COST which you could ask for a cost. > >Like if we'd have a single_set then just temporarily substitute > >the RHS with the candidate and cost the insns and compare against > >the original insn cost. So why exactly do you need a new hook > >for this particular situation? > > Thanks for pointing out this! Segher also mentioned this before. > Currently, CSE is using rtx_cost. Using insn_cost to replace > rtx_cost would be a good idea for all necessary places including CSE.
I have updated many places that used rtx_cost to use insn_cost instead, over the years (as a fallback the generic insn_cost will use rtx_cost). CSE is the biggest remaining thing. There is a long tail left as well of course. > For this particular case: check the cost for constants. > I did not use insn_cost. Because to use insn_cost, we may need > to create a recognizable insn temporarily, and for some kind of > constants we may need to create a sequence instructions on some > platform, e.g. "li xx; ori ; sldi .." on ppc64, and check the > sum cost of those instructions. If only create one fake > instruction, the insn_cost may not return the accurate cost either. That is the problem yes. You need insns to call insn_cost on. You can look in combine.c:combine_validate_cost to see how this can be done; but you need to have some code to generate in the first place, and for CSE it isn't always clear what code to generate, it really is based on RTL expressions having a cost. Segher
