https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #28 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Could somebody benchmark the following patch on zen2 470.lbm.
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 9cee17479ba..76619aca8eb 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -5084,7 +5089,9 @@ lra_constraints (bool first_p)
(x, lra_get_allocno_class (i)) == NO_REGS))
|| contains_symbol_ref_p (x))))
ira_reg_equiv[i].defined_p = false;
- if (contains_reg_p (x, false, true))
+ if (contains_reg_p (x, false, true)
+ || (CONST_DOUBLE_P (x)
+ && maybe_ge (GET_MODE_SIZE (GET_MODE (x)), 8)))
ira_reg_equiv[i].profitable_p = false;
if (get_equiv (reg) != reg)
bitmap_ior_into (equiv_insn_bitmap,
&lra_reg_info[i].insn_bitmap);
If it improves the performance, I'll commit this patch.
The expander unconditionally uses memory pool for double constants. I think
the analogous treatment could be done for equiv double constants in LRA.
I know only x86_64 permits 64-bit constants as immediate for moving them into
general regs. As double fp operations is not done in general regs in the most
cases, they should be moved into fp regs and this is costly as Jan wrote. So
it has sense to prohibit using equiv double constant values in LRA
unconditionally. If in the future we have a target which can move double
immediate into fp regs we can introduce some target hooks to deal with equiv
double constant. But right now I think there is no need for the new hook.
