https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #19 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #16) > (In reply to Wilco from comment #14) > > Note there is also an issue with costs, if the cost is zero then it seems to > > behave like infinite cost. > > 0 means unknown cost. Any known cost is treated as at least as good as > unknown cost. > > > It would be better to properly cost an > > instruction sequence given there is a new interface for this now. > > Yup. > > > If the > > cost is still zero, it could get the default cost rather than being treated > > like infinite cost, resulting in non-optimal replacements. > > Treating unknown cost as minimal cost is still non-optimal. It might work > better for your case of course. But it means for example that combine will > modify parallels less often. Well insn_cost() uses COSTS_N_INSNS (1) for instructions with unknown (zero) costs. That's a reasonable default and gives more accurate cost comparisons, eg. 0 + 4 vs 0 + 8 now becomes 4 + 4 vs 4 + 8. With insn_cost() the ldm's get cost 8+8, so the comparison is 4 + 16 vs 8 + 8, and thus the substitution will happen (though it's not clear it's useful for the selected CPU). With those changes I think there will be far fewer cases with unknown costs. There will be cases where target insn_cost needs to be improved to more accurately model complex instructions, but that will result in even better code.
