Richard Biener <rguent...@suse.de> writes: >> Am 02.04.2025 um 18:31 schrieb Jakub Jelinek <ja...@redhat.com>: >> >> Hi! >> >> Below is an attempt to fix up RTX costing P1 caused by r15-775 >> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/thread.html#652446 >> @@ -21562,7 +21562,8 @@ ix86_rtx_costs (rtx x, machine_mode mode, int >> outer_code_i, int opno, >> if (x86_64_immediate_operand (x, VOIDmode)) >> *total = 0; >> else >> - *total = 1; >> + /* movabsq is slightly more expensive than a simple instruction. */ >> + *total = COSTS_N_INSNS (1) + 1; >> return true; >> >> case CONST_DOUBLE: >> change. In my understanding this was partially trying to workaround >> weird code in pattern_cost, which uses >> return cost > 0 ? cost : COSTS_N_INSNS (1); >> That doesn't make sense to me. All costs smaller than COSTS_N_INSNS (1) >> mean we need to have at least one instruction there which has the >> COSTS_N_INSNS (1) minimal cost. So special casing just cost 0 for the >> really cheap immediates which can be used pretty much everywhere but not >> ones which have just tiny bit larger cost than that (1, 2 or 3) is just >> weird. >> >> So, the following patch changes that to MAX (COSTS_N_INSNS (1), cost) >> which doesn't have this weird behavior where set_src_cost 0 is considered >> more expensive than set_src_cost 1. >> >> Note, pattern_cost isn't the only spot where costs are computed and normally >> we often sum the subcosts of different parts of a pattern or just query >> rtx costs of different parts of subexpressions, so the jump from >> 1 to 5 is quite significant. >> >> Additionally, x86_64 doesn't have just 2 kinds of constants with different >> costs, it has 3, signed 32-bit ones are the ones which can appear in >> almost all instructions and so using cost of 0 for those looks best, >> then unsigned 32-bit ones which can be done with still cheap movl >> instruction (and I think some others too) and finally full 64-bit ones >> which can be done only with a single movabsq instruction and are quite >> costly both in instruction size and even more expensive to execute. >> >> The following patch attempts to restore the behavior of GCC 14 with the >> pattern_cost hunk fixed for the unsigned 32-bit ones and only keeps the >> bigger cost for the 64-bit ones. >> >> Bootstrapped/regtested on x86_64-linux and i686-linux, bootstraps/regtests >> in progress on aarch64-linux, powerpc64le-linux and s390x-linux. >> >> I don't have a setup to test this on SPEC though. >> >> Your thoughts on this? > > I don’t expect any measurable SPEC fallout from this. The biggest effect > might be on RTL if conversion but there I’d guess test coverage is good. > > I’d say the option is to try sth like your patch now (our spec tester will > cover x86 and arm) or demote the regression and try early stage1 with the > option to backport. > > OK for trunk unless there are contrary opinions this week.
+1 for the pattern_cost change. I remember seeing and complaining about the weird condition before, but I was never brave enough to do something about it. Richard
