Hi! On Mon, Jul 06, 2020 at 04:01:54AM +0200, Hans-Peter Nilsson via Gcc-patches wrote: > Most comments, including the second sentence in the head comment > of combine_validate_cost, the main decision-maker of the combine > pass, refer to the function as returning true if the new > insns(s) *cheaper* than the old insns, when in fact the function > returned true also if the cost was the same. Returning true for > cheaper also seems more sane than as-cheap-as considering the > need to avoid oscillation between same-cost combinations. Also, > it makes the job of later passes harder, having combine make > more complex combinations of the same cost.
All of this was added in https://gcc.gnu.org/g:64b8935d4809 , which also adds the + /* Disallow this recombination if both new_cost and old_cost are + greater than zero, and new_cost is greater than old cost. */ comment (which is what it actually does). Before that change, combine didn't look at costs at all. Combine never has used a "strictly smaller than" cost thing. > Right, you can affect this with your target TARGET_RTX_COSTS and > TARGET_INSN_COST hooks, but only for trivial cases, and you have > increasingly more complex combinations (many-to-many > combinations) where you have to twist simple logic to appease > combine (stop it from combining) or give up. There are 2-1, 3-1, 4-1, 3-2, 4-2, which all reduce the number of insns, and then there is 2-2, which gets rid of one log_link. If the isnn_cost stays the same, it always wins something else. > Alternatives from the top of my head, one of: ... 5) Improve your target so that its insn_cost reflects ithe costs of the insns better. Can you share some typical examples where things are worse with the current behaviour? Segher
