Segher Boessenkool <seg...@kernel.crashing.org> writes: > 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.
Hi Segher, Thanks! combine_validate_cost is useful to help me on evaluating the costs of several instructions or replacements. As you pointed out, at CSE, it may not be clear to know what extact insn sequences will be generated. Actually, the same issue also exists on RTL expression. At CSE, it may not clear the exact cost, since the real instructions maybe emitted in very late passes. To get the accurate cost, we may analyze the constant in the hook(insn_cost or rtx_cost) and estimate the possible final instructions and then calculate the costs. We discussed one idea: let the hook insn_cost accept any interim instruction, and estimate the real instruction base on the interim insn, and then return the estimated costs. For example: input insn "r119:DI=0x100803004101001" to insn_cost; and in rs6000_insn_cost (for ppc), analyze constant "0x100803004101001" which would need 5 insns; then rs6000_insn_cost sumarize the cost of 5 insns. A minor concern: because we know that reading this constant from the pool is faster than building it by insns, we will generate instructions to load constant from the pool finally, do not emit 5 real instructions to build the value. So, we are more interested in if it is faster to load from pool or not. BR, Jiufu > > > Segher
