* [PATCH] Turn on LRA on all targets
@ 2023-04-23 16:47 Segher Boessenkool
2023-04-23 17:01 ` Jeff Law
` (5 more replies)
0 siblings, 6 replies; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-23 16:47 UTC (permalink / raw)
To: gcc-patches; +Cc: Segher Boessenkool
This minimal patch enables LRA for all targets. It does not clean up
the target code, nor does it do anything to generic code: it just
deletes all target definitions of TARGET_LRA_P.
There are three kinds of changes:
1) Targets that already always have LRA, but that redefine the hook
anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
really changes for these targets with this patch (but later patches
will delete the superfluous hook implementations).
2) Targets that have LRA selectable. Some of those are probably fine,
since they default to using LRA (arc, mips, s390). Two others don't
though, maybe because there are problems (ft32 and sh). I'd love to
hear from all targets in this category what the status is, how easy it
was to convert, etc.
3) Targets that as of yet never used LRA. Many of those will be fine,
but some others will need a little tuning, and a few might need some
actual improvements to LRA itself. These are cris, epiphany, fr30,
frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
find out how many of those targets are ever tested, and how many of
those work with LRA without further changes, and how well.
I send this patch now so that people can start testing. I don't plan to
commit this for another week at least, for a week after GCC 13 release I
guess? How does that plan sound to people?
This is an RFC, so no changelog, no one can accidentally commit it :-)
I thought about Cc:ing lots and lots of people, should I do that?
Segher
---
gcc/config/alpha/alpha.cc | 3 ---
gcc/config/arc/arc.cc | 2 --
gcc/config/avr/avr.cc | 3 ---
gcc/config/bfin/bfin.cc | 3 ---
gcc/config/c6x/c6x.cc | 3 ---
gcc/config/cris/cris.cc | 3 ---
gcc/config/epiphany/epiphany.cc | 2 --
gcc/config/fr30/fr30.cc | 3 ---
gcc/config/frv/frv.cc | 3 ---
gcc/config/ft32/ft32.cc | 3 ---
gcc/config/gcn/gcn.cc | 2 --
gcc/config/h8300/h8300.cc | 3 ---
gcc/config/ia64/ia64.cc | 3 ---
gcc/config/iq2000/iq2000.cc | 3 ---
gcc/config/lm32/lm32.cc | 2 --
gcc/config/m32c/m32c.cc | 3 ---
gcc/config/m32r/m32r.cc | 3 ---
gcc/config/m68k/m68k.cc | 3 ---
gcc/config/mcore/mcore.cc | 3 ---
gcc/config/microblaze/microblaze.cc | 3 ---
gcc/config/mips/mips.cc | 2 --
gcc/config/mmix/mmix.cc | 3 ---
gcc/config/mn10300/mn10300.cc | 3 ---
gcc/config/msp430/msp430.cc | 3 ---
gcc/config/nvptx/nvptx.cc | 3 ---
gcc/config/pa/pa.cc | 3 ---
gcc/config/pdp11/pdp11.cc | 3 ---
gcc/config/rl78/rl78.cc | 3 ---
gcc/config/rx/rx.cc | 3 ---
gcc/config/s390/s390.cc | 3 ---
gcc/config/sh/sh.cc | 3 ---
gcc/config/sparc/sparc.cc | 3 ---
gcc/config/stormy16/stormy16.cc | 3 ---
gcc/config/vax/vax.cc | 3 ---
gcc/config/visium/visium.cc | 3 ---
gcc/config/xtensa/xtensa.cc | 3 ---
36 files changed, 103 deletions(-)
diff --git a/gcc/config/alpha/alpha.cc b/gcc/config/alpha/alpha.cc
index 1d826085198e..784348dbe787 100644
--- a/gcc/config/alpha/alpha.cc
+++ b/gcc/config/alpha/alpha.cc
@@ -10094,9 +10094,6 @@ alpha_can_change_mode_class (machine_mode from, machine_mode to,
#define TARGET_MANGLE_TYPE alpha_mangle_type
#endif
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p
diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
index 22eb2e9cb459..8cd5a794073f 100644
--- a/gcc/config/arc/arc.cc
+++ b/gcc/config/arc/arc.cc
@@ -804,8 +804,6 @@ static rtx arc_legitimize_address_0 (rtx, rtx, machine_mode mode);
#define TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P \
arc_no_speculation_in_delay_slots_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P arc_lra_p
#define TARGET_REGISTER_PRIORITY arc_register_priority
/* Stores with scaled offsets have different displacement ranges. */
#define TARGET_DIFFERENT_ADDR_DISPLACEMENT_P hook_bool_void_true
diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
index c193430cf073..f2a075381d47 100644
--- a/gcc/config/avr/avr.cc
+++ b/gcc/config/avr/avr.cc
@@ -14663,9 +14663,6 @@ avr_float_lib_compare_returns_bool (machine_mode mode, enum rtx_code)
#undef TARGET_CONVERT_TO_TYPE
#define TARGET_CONVERT_TO_TYPE avr_convert_to_type
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_ADDR_SPACE_SUBSET_P
#define TARGET_ADDR_SPACE_SUBSET_P avr_addr_space_subset_p
diff --git a/gcc/config/bfin/bfin.cc b/gcc/config/bfin/bfin.cc
index c70d2281f068..565f817d2e77 100644
--- a/gcc/config/bfin/bfin.cc
+++ b/gcc/config/bfin/bfin.cc
@@ -5834,9 +5834,6 @@ bfin_conditional_register_usage (void)
#undef TARGET_RETURN_IN_MEMORY
#define TARGET_RETURN_IN_MEMORY bfin_return_in_memory
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P bfin_legitimate_address_p
diff --git a/gcc/config/c6x/c6x.cc b/gcc/config/c6x/c6x.cc
index 15be3b23716b..f4c1af1ab7c3 100644
--- a/gcc/config/c6x/c6x.cc
+++ b/gcc/config/c6x/c6x.cc
@@ -6751,9 +6751,6 @@ c6x_regno_reg_class (int reg)
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P c6x_legitimate_address_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_IN_SMALL_DATA_P
#define TARGET_IN_SMALL_DATA_P c6x_in_small_data_p
#undef TARGET_ASM_SELECT_RTX_SECTION
diff --git a/gcc/config/cris/cris.cc b/gcc/config/cris/cris.cc
index 05dead9c0778..7ce1b754e76e 100644
--- a/gcc/config/cris/cris.cc
+++ b/gcc/config/cris/cris.cc
@@ -215,9 +215,6 @@ int cris_cpu_version = CRIS_DEFAULT_CPU_VERSION;
#undef TARGET_INIT_LIBFUNCS
#define TARGET_INIT_LIBFUNCS cris_init_libfuncs
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P cris_legitimate_address_p
diff --git a/gcc/config/epiphany/epiphany.cc b/gcc/config/epiphany/epiphany.cc
index fdd4df71456b..20c20e18ea0f 100644
--- a/gcc/config/epiphany/epiphany.cc
+++ b/gcc/config/epiphany/epiphany.cc
@@ -106,8 +106,6 @@ static rtx_insn *frame_insn (rtx);
#define TARGET_SCHED_ISSUE_RATE epiphany_issue_rate
#define TARGET_SCHED_ADJUST_COST epiphany_adjust_cost
-#define TARGET_LRA_P hook_bool_void_false
-
#define TARGET_LEGITIMATE_ADDRESS_P epiphany_legitimate_address_p
#define TARGET_SECONDARY_RELOAD epiphany_secondary_reload
diff --git a/gcc/config/fr30/fr30.cc b/gcc/config/fr30/fr30.cc
index 0d05b13aa31e..d2b2bf39c7f9 100644
--- a/gcc/config/fr30/fr30.cc
+++ b/gcc/config/fr30/fr30.cc
@@ -185,9 +185,6 @@ static int fr30_num_arg_regs (const function_arg_info &);
#undef TARGET_CAN_ELIMINATE
#define TARGET_CAN_ELIMINATE fr30_can_eliminate
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_ASM_TRAMPOLINE_TEMPLATE
#define TARGET_ASM_TRAMPOLINE_TEMPLATE fr30_asm_trampoline_template
#undef TARGET_TRAMPOLINE_INIT
diff --git a/gcc/config/frv/frv.cc b/gcc/config/frv/frv.cc
index 99f79325cd6f..71f6d92e2abb 100644
--- a/gcc/config/frv/frv.cc
+++ b/gcc/config/frv/frv.cc
@@ -496,9 +496,6 @@ static bool frv_modes_tieable_p (machine_mode, machine_mode);
#undef TARGET_SECONDARY_RELOAD
#define TARGET_SECONDARY_RELOAD frv_secondary_reload
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P frv_legitimate_address_p
diff --git a/gcc/config/ft32/ft32.cc b/gcc/config/ft32/ft32.cc
index 806ab769f795..dfca7883ab65 100644
--- a/gcc/config/ft32/ft32.cc
+++ b/gcc/config/ft32/ft32.cc
@@ -840,9 +840,6 @@ ft32_lra_p (void)
return ft32_lra_flag;
}
-#undef TARGET_LRA_P
-#define TARGET_LRA_P ft32_lra_p
-
static bool
reg_ok_for_base_p (rtx r, bool strict)
{
diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index 5608d85a1a07..d2f92e50bc6e 100644
--- a/gcc/config/gcn/gcn.cc
+++ b/gcc/config/gcn/gcn.cc
@@ -7510,8 +7510,6 @@ gcn_dwarf_register_span (rtx rtl)
#define TARGET_LEGITIMATE_CONSTANT_P gcn_legitimate_constant_p
#undef TARGET_LIBC_HAS_FUNCTION
#define TARGET_LIBC_HAS_FUNCTION gcn_libc_has_function
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_true
#undef TARGET_MACHINE_DEPENDENT_REORG
#define TARGET_MACHINE_DEPENDENT_REORG gcn_md_reorg
#undef TARGET_MEMORY_MOVE_COST
diff --git a/gcc/config/h8300/h8300.cc b/gcc/config/h8300/h8300.cc
index c3674933f900..815267393cb1 100644
--- a/gcc/config/h8300/h8300.cc
+++ b/gcc/config/h8300/h8300.cc
@@ -5625,9 +5625,6 @@ pre_incdec_with_reg (rtx op, unsigned int reg)
#undef TARGET_MODES_TIEABLE_P
#define TARGET_MODES_TIEABLE_P h8300_modes_tieable_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P h8300_legitimate_address_p
diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc
index f32efb3bd803..dd11709072e5 100644
--- a/gcc/config/ia64/ia64.cc
+++ b/gcc/config/ia64/ia64.cc
@@ -608,9 +608,6 @@ static const struct attribute_spec ia64_attribute_table[] =
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_CANNOT_FORCE_CONST_MEM
#define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem
diff --git a/gcc/config/iq2000/iq2000.cc b/gcc/config/iq2000/iq2000.cc
index de44d361080b..067154a0a0d9 100644
--- a/gcc/config/iq2000/iq2000.cc
+++ b/gcc/config/iq2000/iq2000.cc
@@ -241,9 +241,6 @@ static HOST_WIDE_INT iq2000_starting_frame_offset (void);
#undef TARGET_EXPAND_BUILTIN_VA_START
#define TARGET_EXPAND_BUILTIN_VA_START iq2000_va_start
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P iq2000_legitimate_address_p
diff --git a/gcc/config/lm32/lm32.cc b/gcc/config/lm32/lm32.cc
index 37a6eb86da05..3f1d9d388993 100644
--- a/gcc/config/lm32/lm32.cc
+++ b/gcc/config/lm32/lm32.cc
@@ -104,8 +104,6 @@ static HOST_WIDE_INT lm32_starting_frame_offset (void);
#define TARGET_MAX_ANCHOR_OFFSET 0x7fff
#undef TARGET_CAN_ELIMINATE
#define TARGET_CAN_ELIMINATE lm32_can_eliminate
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P lm32_legitimate_address_p
#undef TARGET_HARD_REGNO_MODE_OK
diff --git a/gcc/config/m32c/m32c.cc b/gcc/config/m32c/m32c.cc
index e0d06f833d3d..691014f52232 100644
--- a/gcc/config/m32c/m32c.cc
+++ b/gcc/config/m32c/m32c.cc
@@ -1636,9 +1636,6 @@ m32c_trampoline_init (rtx m_tramp, tree fndecl, rtx chainval)
#undef A0
}
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
/* Addressing Modes */
/* The r8c/m32c family supports a wide range of non-orthogonal
diff --git a/gcc/config/m32r/m32r.cc b/gcc/config/m32r/m32r.cc
index 5a788e295154..155a248459bc 100644
--- a/gcc/config/m32r/m32r.cc
+++ b/gcc/config/m32r/m32r.cc
@@ -127,9 +127,6 @@ static const struct attribute_spec m32r_attribute_table[] =
#undef TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P
#define TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P m32r_attribute_identifier
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P m32r_legitimate_address_p
#undef TARGET_LEGITIMIZE_ADDRESS
diff --git a/gcc/config/m68k/m68k.cc b/gcc/config/m68k/m68k.cc
index 03db2b6a9369..64e7d3bca620 100644
--- a/gcc/config/m68k/m68k.cc
+++ b/gcc/config/m68k/m68k.cc
@@ -303,9 +303,6 @@ static void m68k_asm_final_postscan_insn (FILE *, rtx_insn *insn, rtx [], int);
#define TARGET_ASM_OUTPUT_DWARF_DTPREL m68k_output_dwarf_dtprel
#endif
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P m68k_legitimate_address_p
diff --git a/gcc/config/mcore/mcore.cc b/gcc/config/mcore/mcore.cc
index e800af78e14b..384d702ed77f 100644
--- a/gcc/config/mcore/mcore.cc
+++ b/gcc/config/mcore/mcore.cc
@@ -237,9 +237,6 @@ static const struct attribute_spec mcore_attribute_table[] =
#undef TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
#define TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P mcore_legitimate_address_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_WARN_FUNC_RETURN
#define TARGET_WARN_FUNC_RETURN mcore_warn_func_return
diff --git a/gcc/config/microblaze/microblaze.cc b/gcc/config/microblaze/microblaze.cc
index 6df2c712cab1..ebe78304f898 100644
--- a/gcc/config/microblaze/microblaze.cc
+++ b/gcc/config/microblaze/microblaze.cc
@@ -4017,9 +4017,6 @@ microblaze_starting_frame_offset (void)
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P microblaze_legitimate_address_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_FRAME_POINTER_REQUIRED
#define TARGET_FRAME_POINTER_REQUIRED microblaze_frame_pointer_required
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index ca822758b41c..b5e225896da9 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -23011,8 +23011,6 @@ mips_asm_file_end (void)
#undef TARGET_SPILL_CLASS
#define TARGET_SPILL_CLASS mips_spill_class
-#undef TARGET_LRA_P
-#define TARGET_LRA_P mips_lra_p
#undef TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
#define TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS mips_ira_change_pseudo_allocno_class
diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index 4e4fb8bdac27..eda2959adb96 100644
--- a/gcc/config/mmix/mmix.cc
+++ b/gcc/config/mmix/mmix.cc
@@ -273,9 +273,6 @@ static HOST_WIDE_INT mmix_starting_frame_offset (void);
#undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
#define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS mmix_preferred_output_reload_class
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P mmix_legitimate_address_p
#undef TARGET_LEGITIMATE_CONSTANT_P
diff --git a/gcc/config/mn10300/mn10300.cc b/gcc/config/mn10300/mn10300.cc
index a8b01a543cc7..4540858d312e 100644
--- a/gcc/config/mn10300/mn10300.cc
+++ b/gcc/config/mn10300/mn10300.cc
@@ -3368,9 +3368,6 @@ mn10300_reorg (void)
#undef TARGET_CASE_VALUES_THRESHOLD
#define TARGET_CASE_VALUES_THRESHOLD mn10300_case_values_threshold
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P mn10300_legitimate_address_p
#undef TARGET_DELEGITIMIZE_ADDRESS
diff --git a/gcc/config/msp430/msp430.cc b/gcc/config/msp430/msp430.cc
index 6f9c56187ee3..1af0223cb394 100644
--- a/gcc/config/msp430/msp430.cc
+++ b/gcc/config/msp430/msp430.cc
@@ -902,9 +902,6 @@ msp430_gimplify_va_arg_expr (tree valist, tree type, gimple_seq *pre_p,
return addr;
}
\f
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
/* Addressing Modes */
#undef TARGET_LEGITIMATE_ADDRESS_P
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index 89349dae9e62..e32f17377525 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -7601,9 +7601,6 @@ nvptx_asm_output_def_from_decls (FILE *stream, tree name, tree value)
#undef TARGET_ATTRIBUTE_TABLE
#define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P nvptx_legitimate_address_p
diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
index db633b275e5e..2198140cb492 100644
--- a/gcc/config/pa/pa.cc
+++ b/gcc/config/pa/pa.cc
@@ -403,9 +403,6 @@ static size_t n_deferred_plabels = 0;
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P pa_legitimate_address_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_HARD_REGNO_NREGS
#define TARGET_HARD_REGNO_NREGS pa_hard_regno_nregs
#undef TARGET_HARD_REGNO_MODE_OK
diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
index 4af26f8cd709..528dfd59a770 100644
--- a/gcc/config/pdp11/pdp11.cc
+++ b/gcc/config/pdp11/pdp11.cc
@@ -228,9 +228,6 @@ static bool pdp11_scalar_mode_supported_p (scalar_mode);
#undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
#define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS pdp11_preferred_output_reload_class
-#undef TARGET_LRA_P
-#define TARGET_LRA_P pdp11_lra_p
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P pdp11_legitimate_address_p
diff --git a/gcc/config/rl78/rl78.cc b/gcc/config/rl78/rl78.cc
index 7ed28d35883a..440eb134b349 100644
--- a/gcc/config/rl78/rl78.cc
+++ b/gcc/config/rl78/rl78.cc
@@ -1135,9 +1135,6 @@ rl78_is_legitimate_constant (machine_mode mode ATTRIBUTE_UNUSED, rtx x ATTRIBUTE
return true;
}
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
#define TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P rl78_as_legitimate_address
diff --git a/gcc/config/rx/rx.cc b/gcc/config/rx/rx.cc
index 726b00a3193b..64a30963e7f5 100644
--- a/gcc/config/rx/rx.cc
+++ b/gcc/config/rx/rx.cc
@@ -3790,9 +3790,6 @@ rx_modes_tieable_p (machine_mode mode1, machine_mode mode2)
#undef TARGET_WARN_FUNC_RETURN
#define TARGET_WARN_FUNC_RETURN rx_warn_func_return
-#undef TARGET_LRA_P
-#define TARGET_LRA_P rx_enable_lra
-
#undef TARGET_HARD_REGNO_NREGS
#define TARGET_HARD_REGNO_NREGS rx_hard_regno_nregs
#undef TARGET_HARD_REGNO_MODE_OK
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 505de995da87..639c1e483003 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -17706,9 +17706,6 @@ s390_vectorize_vec_perm_const (machine_mode vmode, machine_mode op_mode,
#undef TARGET_LEGITIMATE_CONSTANT_P
#define TARGET_LEGITIMATE_CONSTANT_P s390_legitimate_constant_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P s390_lra_p
-
#undef TARGET_CAN_ELIMINATE
#define TARGET_CAN_ELIMINATE s390_can_eliminate
diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index cf6188bd19db..fae58b3e574a 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -593,9 +593,6 @@ static const struct attribute_spec sh_attribute_table[] =
#undef TARGET_ENCODE_SECTION_INFO
#define TARGET_ENCODE_SECTION_INFO sh_encode_section_info
-#undef TARGET_LRA_P
-#define TARGET_LRA_P sh_lra_p
-
#undef TARGET_SECONDARY_RELOAD
#define TARGET_SECONDARY_RELOAD sh_secondary_reload
diff --git a/gcc/config/sparc/sparc.cc b/gcc/config/sparc/sparc.cc
index 8c0c9dce9714..48204ffaf625 100644
--- a/gcc/config/sparc/sparc.cc
+++ b/gcc/config/sparc/sparc.cc
@@ -910,9 +910,6 @@ char sparc_hard_reg_printed[8];
#define TARGET_MANGLE_TYPE sparc_mangle_type
#endif
-#undef TARGET_LRA_P
-#define TARGET_LRA_P sparc_lra_p
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P sparc_legitimate_address_p
diff --git a/gcc/config/stormy16/stormy16.cc b/gcc/config/stormy16/stormy16.cc
index 1ed619a28968..4bfe846fc8ce 100644
--- a/gcc/config/stormy16/stormy16.cc
+++ b/gcc/config/stormy16/stormy16.cc
@@ -2719,9 +2719,6 @@ xstormy16_push_rounding (poly_int64 bytes)
#undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
#define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS xstormy16_preferred_reload_class
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P xstormy16_legitimate_address_p
#undef TARGET_MODE_DEPENDENT_ADDRESS_P
diff --git a/gcc/config/vax/vax.cc b/gcc/config/vax/vax.cc
index 82a176d3bfc9..17fdc4483797 100644
--- a/gcc/config/vax/vax.cc
+++ b/gcc/config/vax/vax.cc
@@ -114,9 +114,6 @@ static HOST_WIDE_INT vax_starting_frame_offset (void);
#undef TARGET_STRUCT_VALUE_RTX
#define TARGET_STRUCT_VALUE_RTX vax_struct_value_rtx
-#undef TARGET_LRA_P
-#define TARGET_LRA_P vax_lra_p
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P vax_legitimate_address_p
#undef TARGET_MODE_DEPENDENT_ADDRESS_P
diff --git a/gcc/config/visium/visium.cc b/gcc/config/visium/visium.cc
index ec4c2e9ae5cb..c727b5d6d29d 100644
--- a/gcc/config/visium/visium.cc
+++ b/gcc/config/visium/visium.cc
@@ -280,9 +280,6 @@ static HOST_WIDE_INT visium_constant_alignment (const_tree, HOST_WIDE_INT);
#undef TARGET_LEGITIMATE_CONSTANT_P
#define TARGET_LEGITIMATE_CONSTANT_P visium_legitimate_constant_p
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P visium_legitimate_address_p
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 9e5d314e143e..4c98f3071c4d 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -286,9 +286,6 @@ static rtx xtensa_delegitimize_address (rtx);
#undef TARGET_CANNOT_FORCE_CONST_MEM
#define TARGET_CANNOT_FORCE_CONST_MEM xtensa_cannot_force_const_mem
-#undef TARGET_LRA_P
-#define TARGET_LRA_P xtensa_lra_p
-
#undef TARGET_LEGITIMATE_ADDRESS_P
#define TARGET_LEGITIMATE_ADDRESS_P xtensa_legitimate_address_p
--
1.8.3.1
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
@ 2023-04-23 17:01 ` Jeff Law
2023-04-23 20:23 ` Segher Boessenkool
2023-04-24 8:42 ` Andreas Schwab
2023-04-23 18:36 ` Paul Koning
` (4 subsequent siblings)
5 siblings, 2 replies; 31+ messages in thread
From: Jeff Law @ 2023-04-23 17:01 UTC (permalink / raw)
To: gcc-patches
On 4/23/23 10:47, Segher Boessenkool wrote:
> 3) Targets that as of yet never used LRA. Many of those will be fine,
> but some others will need a little tuning, and a few might need some
> actual improvements to LRA itself. These are cris, epiphany, fr30,
> frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
> find out how many of those targets are ever tested, and how many of
> those work with LRA without further changes, and how well.
These test daily except for m68k and pa which test weekly ;-)
Jeff
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-23 17:01 ` Jeff Law
@ 2023-04-23 20:23 ` Segher Boessenkool
2023-04-24 8:42 ` Andreas Schwab
1 sibling, 0 replies; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-23 20:23 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches
(You didn't leave me in Cc: on the reply. Maybe you did a
reply-to-only-one-person?)
On Sun, Apr 23, 2023 at 11:01:05AM -0600, Jeff Law via Gcc-patches wrote:
> On 4/23/23 10:47, Segher Boessenkool wrote:
> >3) Targets that as of yet never used LRA. Many of those will be fine,
> >but some others will need a little tuning, and a few might need some
> >actual improvements to LRA itself. These are cris, epiphany, fr30,
> >frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> >mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
> >find out how many of those targets are ever tested, and how many of
> >those work with LRA without further changes, and how well.
> These test daily except for m68k and pa which test weekly ;-)
Ah, very good! But still none of them are tested with LRA at all, after
so many years :-(
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 17:01 ` Jeff Law
2023-04-23 20:23 ` Segher Boessenkool
@ 2023-04-24 8:42 ` Andreas Schwab
1 sibling, 0 replies; 31+ messages in thread
From: Andreas Schwab @ 2023-04-24 8:42 UTC (permalink / raw)
To: Jeff Law via Gcc-patches; +Cc: Jeff Law
Here is the result for m68k:
libtool: compile: /daten/aranym/gcc/gcc-20230424/Build/./gcc/xgcc -shared-libgcc -B/daten/aranym/gcc/gcc-20230424/Build/./gcc -nostdinc++ -L/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/src -L/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/src/.libs -L/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/libsupc++/.libs -B/daten/cross/m68k-linux/m68k-linux/bin/ -B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem /daten/cross/m68k-linux/m68k-linux/include -isystem /daten/cross/m68k-linux/m68k-linux/sys-include -I/daten/aranym/gcc/gcc-20230424/libstdc++-v3/../libgcc -I/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/include/m68k-linux -I/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/include -I/daten/aranym/gcc/gcc-20230424/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=wlocale-inst.lo -g -O2 -D_GNU_SOURCE -c ../../../../../libstdc++-v3/src/c++11/wlocale-inst.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o wlocale-inst.o
during RTL pass: reload
In file included from /daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/include/bits/locale_facets.h:2687,
from /daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/include/locale:42,
from ../../../../../libstdc++-v3/src/c++11/locale-inst.cc:38,
from ../../../../../libstdc++-v3/src/c++11/wlocale-inst.cc:35:
/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/include/bits/locale_facets.tcc: In member function '_InIter std::num_get<_CharT, _InIter>::do_get(iter_type, iter_type, std::ios_base&, std::ios_base::iostate&, bool&) const [with _CharT = wchar_t; _InIter = std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >]':
/daten/aranym/gcc/gcc-20230424/Build/m68k-linux/libstdc++-v3/include/bits/locale_facets.tcc:686:5: internal compiler error: maximum number of generated reload insns per insn achieved (90)
686 | }
| ^
0xe8a5e8 lra_constraints(bool)
../../gcc/lra-constraints.cc:5319
0xe71f32 lra(_IO_FILE*)
../../gcc/lra.cc:2375
0xe21731 do_reload
../../gcc/ira.cc:5967
0xe21731 execute
../../gcc/ira.cc:6153
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
2023-04-23 17:01 ` Jeff Law
@ 2023-04-23 18:36 ` Paul Koning
2023-04-23 20:19 ` Segher Boessenkool
2023-04-23 18:56 ` Maciej W. Rozycki
` (3 subsequent siblings)
5 siblings, 1 reply; 31+ messages in thread
From: Paul Koning @ 2023-04-23 18:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-patches
> On Apr 23, 2023, at 12:47 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> This minimal patch enables LRA for all targets. It does not clean up
> the target code, nor does it do anything to generic code: it just
> deletes all target definitions of TARGET_LRA_P.
>
> There are three kinds of changes:
>
> 1) Targets that already always have LRA, but that redefine the hook
> anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).
I thought that the existing coding for pdp11 makes LRA selectable (via -mlra) and defaults to off. I had planned to change it to default to on but leave it selectable. I suppose just having it on is ok too, although the code from LRA wasn't as efficient as the old last I looked (which is a while ago).
paul
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-23 18:36 ` Paul Koning
@ 2023-04-23 20:19 ` Segher Boessenkool
0 siblings, 0 replies; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-23 20:19 UTC (permalink / raw)
To: Paul Koning; +Cc: gcc-patches
Hi!
On Sun, Apr 23, 2023 at 02:36:05PM -0400, Paul Koning wrote:
> > On Apr 23, 2023, at 12:47 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > 1) Targets that already always have LRA, but that redefine the hook
> > anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> > really changes for these targets with this patch (but later patches
> > will delete the superfluous hook implementations).
>
> I thought that the existing coding for pdp11 makes LRA selectable (via -mlra) and defaults to off.
static bool
pdp11_lra_p (void)
{
return TARGET_LRA;
}
Ah, that is a target flag, not an enum value or such? Aha!
mlra
Target Mask(LRA)
Use LRA register allocator.
This is true for sparc and vax and xtensa as well, and rx with
TARGET_ENABLE_LRA. gcn does in fact do
#define TARGET_LRA_P hook_bool_void_true
which is a funny way to have the same effect as not defining it at all.
So these five targets are category 2). Thanks for correcting me!
> I had planned to change it to default to on but leave it selectable. I suppose just having it on is ok too, although the code from LRA wasn't as efficient as the old last I looked (which is a while ago).
The plan is to delete old reload completely, with all follow-up
simplifications and cleanups.
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
2023-04-23 17:01 ` Jeff Law
2023-04-23 18:36 ` Paul Koning
@ 2023-04-23 18:56 ` Maciej W. Rozycki
2023-04-23 20:33 ` Segher Boessenkool
2023-04-23 21:06 ` Uros Bizjak
` (2 subsequent siblings)
5 siblings, 1 reply; 31+ messages in thread
From: Maciej W. Rozycki @ 2023-04-23 18:56 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-patches
On Sun, 23 Apr 2023, Segher Boessenkool wrote:
> 1) Targets that already always have LRA, but that redefine the hook
> anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).
Umm, no, VAX has LRA selectable and for a reason it defaults to off:
> diff --git a/gcc/config/vax/vax.cc b/gcc/config/vax/vax.cc
> index 82a176d3bfc9..17fdc4483797 100644
> --- a/gcc/config/vax/vax.cc
> +++ b/gcc/config/vax/vax.cc
> @@ -114,9 +114,6 @@ static HOST_WIDE_INT vax_starting_frame_offset (void);
> #undef TARGET_STRUCT_VALUE_RTX
> #define TARGET_STRUCT_VALUE_RTX vax_struct_value_rtx
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P vax_lra_p
> -
There are extra ICEs in regression testing and code quality is poor; cf.
<https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588296.html>.
I'll have a look into it sometime, but it may not be soon and the broken
VAX exception unwinder is more important and will have to take precedence
anyway. I have fixing the unwinder scheduled hopefully for this release
cycle, but LRA will have to wait.
Maciej
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-23 18:56 ` Maciej W. Rozycki
@ 2023-04-23 20:33 ` Segher Boessenkool
2023-05-15 21:09 ` Maciej W. Rozycki
0 siblings, 1 reply; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-23 20:33 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gcc-patches
On Sun, Apr 23, 2023 at 07:56:56PM +0100, Maciej W. Rozycki wrote:
> On Sun, 23 Apr 2023, Segher Boessenkool wrote:
> > 1) Targets that already always have LRA, but that redefine the hook
> > anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> > really changes for these targets with this patch (but later patches
> > will delete the superfluous hook implementations).
>
> Umm, no, VAX has LRA selectable and for a reason it defaults to off:
I read TARGET_LRA as something that denotes LRA is selected :-) See the
other mail. So, vax is in category 2).
> There are extra ICEs in regression testing and code quality is poor; cf.
> <https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588296.html>.
Do you have something you can show for this? Maybe in a PR?
And, are the ICEs in the generic code, or something vax-specific?
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 20:33 ` Segher Boessenkool
@ 2023-05-15 21:09 ` Maciej W. Rozycki
2023-05-15 21:16 ` Sam James
2024-02-15 22:21 ` Paul Koning
0 siblings, 2 replies; 31+ messages in thread
From: Maciej W. Rozycki @ 2023-05-15 21:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-patches
On Sun, 23 Apr 2023, Segher Boessenkool wrote:
> > There are extra ICEs in regression testing and code quality is poor; cf.
> > <https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588296.html>.
>
> Do you have something you can show for this? Maybe in a PR?
I have filed no PRs as I didn't assess the collateral damage at the time
I looked at it. I only ran regression-testing with `-mlra' shortly after
I completed MODE_CC conversion and added the option, to see what lies
beyond. And I only added `-mlra' and made minimal changes to make the
compiler build again just to make it easier to proceed towards LRA.
> And, are the ICEs in the generic code, or something vax-specific?
At least some were in generic code, e.g.:
during RTL pass: combine
.../gcc/testsuite/gcc.c-torture/compile/pr101562.c: In function 'foo':
.../gcc/testsuite/gcc.c-torture/compile/pr101562.c:12:1: internal compiler error: in insert, at wide-int.cc:682
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
compiler exited with status 1
FAIL: gcc.c-torture/compile/pr101562.c -O1 (internal compiler error)
FAIL: gcc.c-torture/compile/pr101562.c -O1 (test for excess errors)
(coming from `gcc_checking_assert (precision >= width)'), or:
In file included from .../gcc/testsuite/g++.dg/modules/xtreme-header-2.h:10,
from .../gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H:4:
.../vax-netbsdelf/libstdc++-v3/include/regex:42: internal compiler error: in set_filename, at cp/module.cc:19134
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
compiler exited with status 1
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors)
(from `gcc_checking_assert (!filename)'). As I say, I did not assess this
at all back then and the logs are dated Nov 2021 (I had to chase them).
Also I'm not going to dedicate any time now to switch the VAX backend to
LRA, because old reload continues working while we have a non-functional
exception unwinder that never ever worked, as I have recently discovered,
which breaks lots of C++ code, including in particular native VAX/NetBSD
GDB and `gdbserver' (my newly-ported implementation of), which is a bit of
a problem (native VAX/NetBSD GCC has been spared owing to the decision not
to use exceptions).
And fixing the unwinder is going to be a major effort due to how the VAX
CALLS machine instruction works and the stack frame has been consequently
structured; it is unlike any other ELF target, and even if it can be
expressed in DWARF terms (which I'm not entirely sure about), it is going
to require a dedicated handler like with ARM or IA64.
I may choose to implement a non-DWARF unwinder instead, as the VAX stack
frame is always fully described by the hardware and there is never ever a
need for debug information to be able to decode any VAX stack frame (the
RET machine instruction uses the stack frame information to restore the
previous PC, FP, SP, AP and any static registers saved by CALLS).
So implementing a working exception unwinder has to take precedence over
LRA and I do hope to complete it during this release cycle, but I may not
have any time left for LRA.
Please keep this in mind with any plans to drop old reload. I'll highly
appreciate that and I do keep LRA on my radar as the next item to address
after the unwinder, by any means it's not been lost.
Maciej
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-05-15 21:09 ` Maciej W. Rozycki
@ 2023-05-15 21:16 ` Sam James
2024-02-15 19:34 ` Sam James
2024-02-15 22:21 ` Paul Koning
1 sibling, 1 reply; 31+ messages in thread
From: Sam James @ 2023-05-15 21:16 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Segher Boessenkool, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
"Maciej W. Rozycki" <macro@orcam.me.uk> writes:
> On Sun, 23 Apr 2023, Segher Boessenkool wrote:
>
>> > There are extra ICEs in regression testing and code quality is poor; cf.
>> > <https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588296.html>.
>>
>> Do you have something you can show for this? Maybe in a PR?
>
> I have filed no PRs as I didn't assess the collateral damage at the time
> I looked at it. I only ran regression-testing with `-mlra' shortly after
> I completed MODE_CC conversion and added the option, to see what lies
> beyond. And I only added `-mlra' and made minimal changes to make the
> compiler build again just to make it easier to proceed towards LRA.
I think before moving forward with the plan in general, a PR is ideally
needed for each target anyway. Not all machine maintainers actively watch the
MLs.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-05-15 21:16 ` Sam James
@ 2024-02-15 19:34 ` Sam James
2024-02-15 22:56 ` Segher Boessenkool
0 siblings, 1 reply; 31+ messages in thread
From: Sam James @ 2024-02-15 19:34 UTC (permalink / raw)
To: Sam James; +Cc: Maciej W. Rozycki, Segher Boessenkool, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
Sam James <sam@gentoo.org> writes:
> [[PGP Signed Part:Undecided]]
>
> "Maciej W. Rozycki" <macro@orcam.me.uk> writes:
>
>> On Sun, 23 Apr 2023, Segher Boessenkool wrote:
>>
>>> > There are extra ICEs in regression testing and code quality is poor; cf.
>>> > <https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588296.html>.
>>>
>>> Do you have something you can show for this? Maybe in a PR?
>>
>> I have filed no PRs as I didn't assess the collateral damage at the time
>> I looked at it. I only ran regression-testing with `-mlra' shortly after
>> I completed MODE_CC conversion and added the option, to see what lies
>> beyond. And I only added `-mlra' and made minimal changes to make the
>> compiler build again just to make it easier to proceed towards LRA.
>
> I think before moving forward with the plan in general, a PR is ideally
> needed for each target anyway. Not all machine maintainers actively watch the
> MLs.
I have now started doing this in PR113932.
>
> [[End of PGP Signed Part]]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-15 19:34 ` Sam James
@ 2024-02-15 22:56 ` Segher Boessenkool
2024-02-16 1:41 ` Paul Koning
0 siblings, 1 reply; 31+ messages in thread
From: Segher Boessenkool @ 2024-02-15 22:56 UTC (permalink / raw)
To: Sam James; +Cc: Maciej W. Rozycki, gcc-patches
On Thu, Feb 15, 2024 at 07:34:32PM +0000, Sam James wrote:
> I have now started doing this in PR113932.
Thank you!
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-15 22:56 ` Segher Boessenkool
@ 2024-02-16 1:41 ` Paul Koning
2024-02-16 10:22 ` Segher Boessenkool
0 siblings, 1 reply; 31+ messages in thread
From: Paul Koning @ 2024-02-16 1:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Sam James, Maciej W. Rozycki, gcc-patches
> On Feb 15, 2024, at 5:56 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> On Thu, Feb 15, 2024 at 07:34:32PM +0000, Sam James wrote:
>> I have now started doing this in PR113932.
>
> Thank you!
>
> Segher
Presumably this isn't for version 14 since it's in a late stage, right? I have my bits about ready to go in but I'll wait for State 1 to open. Correct?
paul
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-16 1:41 ` Paul Koning
@ 2024-02-16 10:22 ` Segher Boessenkool
0 siblings, 0 replies; 31+ messages in thread
From: Segher Boessenkool @ 2024-02-16 10:22 UTC (permalink / raw)
To: Paul Koning; +Cc: Sam James, Maciej W. Rozycki, gcc-patches
On Thu, Feb 15, 2024 at 08:41:42PM -0500, Paul Koning wrote:
> > On Feb 15, 2024, at 5:56 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >
> > On Thu, Feb 15, 2024 at 07:34:32PM +0000, Sam James wrote:
> >> I have now started doing this in PR113932.
> >
> > Thank you!
> >
> > Segher
>
> Presumably this isn't for version 14 since it's in a late stage, right? I have my bits about ready to go in but I'll wait for State 1 to open. Correct?
Absolutely. It was decided early in stage 1 that this wasn't going to
happen for 14.
It appears most of the anywhere near hard targets have not done anything
though. I'll just push very hard for 15. But you will be fine :-)
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-05-15 21:09 ` Maciej W. Rozycki
2023-05-15 21:16 ` Sam James
@ 2024-02-15 22:21 ` Paul Koning
2024-02-16 11:34 ` Maciej W. Rozycki
1 sibling, 1 reply; 31+ messages in thread
From: Paul Koning @ 2024-02-15 22:21 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Segher Boessenkool, gcc-patches
> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> ...
>
> I may choose to implement a non-DWARF unwinder instead, as the VAX stack
> frame is always fully described by the hardware and there is never ever a
> need for debug information to be able to decode any VAX stack frame (the
> RET machine instruction uses the stack frame information to restore the
> previous PC, FP, SP, AP and any static registers saved by CALLS).
That would make sense; it's like the heuristic unwinder found in some other targets (I remember the MIPS one, which worked fairly well and allowed debugging without useable debug data).
paul
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-15 22:21 ` Paul Koning
@ 2024-02-16 11:34 ` Maciej W. Rozycki
2024-02-16 13:47 ` Segher Boessenkool
2024-02-16 14:50 ` Paul Koning
0 siblings, 2 replies; 31+ messages in thread
From: Maciej W. Rozycki @ 2024-02-16 11:34 UTC (permalink / raw)
To: Paul Koning; +Cc: Segher Boessenkool, gcc-patches
On Thu, 15 Feb 2024, Paul Koning wrote:
> > On May 15, 2023, at 5:09 PM, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> >
> > ...
> >
> > I may choose to implement a non-DWARF unwinder instead, as the VAX stack
> > frame is always fully described by the hardware and there is never ever a
> > need for debug information to be able to decode any VAX stack frame (the
> > RET machine instruction uses the stack frame information to restore the
> > previous PC, FP, SP, AP and any static registers saved by CALLS).
>
> That would make sense; it's like the heuristic unwinder found in some
> other targets (I remember the MIPS one, which worked fairly well and
> allowed debugging without useable debug data).
Not really, in particular because EH unwinding has to be reliable and
heuristics inherently is not.
The MIPS heuristic unwinder continues living in GDB; I have extended it
to the microMIPS ISA at one point. It has a major flaw though: the MIPS
psABI uses a variable frame layout, with the frame maintained solely by
software and with no fixed hardware frame pointer, so to analyse it in the
absence of debug information the instruction sequence of the function's in
question prologue has to be decoded to discover the location of individual
frame slots.
Consequently the more aggressive the compiler has become to schedule
function body instructions within a function's prologue the more lost the
machine code interpreter has become. Ultimately it would have to become a
full-fledged CPU simulator to do its heuristics. In reality it means the
unwinder may fail to produce acceptable results, which will happen at any
frequency between hardly ever to most often, depending on the exact
circumstances.
A mixed approach by interpreting lightweight PDR (Procedure Description
Record) information inherited from the ECOFF Mdebug format combined with
function prologue scanning might be more reliable, because in that case
frame slot positions are known and the only unknown is the code locations
they are initialised each at. So all the prologue scanner has to know it
is the store machine instructions and any that set a frame pointer from
the stack pointer. All the other instructions can be simply ignored. And
then only in the innermost frame, because any outer frames must have been
fully set up already. But I never got to implementing it and remnants of
the PDR unwinder have long been removed from GDB.
Conversely no heuristics is required to unwind VAX frames, because they
are fixed in layout by hardware, fully self-described, and with the
hardware frame pointer always available. Therefore to unwind a VAX frame
steps similar to those made by hardware on a function return (machine RET
instruction) can simply be recreated from information produced by hardware
at the function call and recorded in the stack frame and registers. There
is room reserved in the stack frame for a pointer to an exception handler
even ("condition handler" in VAX-speak), preset to zero (a null pointer)
by hardware at function entry.
It does seem really attractive (and saves some storage space, which VAX
hardware users will likely appreciate), but implies dedicated libgcc code
as opposed to reusing common bits, which may or may not be welcome by the
community for such an exotic corner case target.
Maciej
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2024-02-16 11:34 ` Maciej W. Rozycki
@ 2024-02-16 13:47 ` Segher Boessenkool
2024-02-16 14:23 ` Maciej W. Rozycki
2024-02-16 14:50 ` Paul Koning
1 sibling, 1 reply; 31+ messages in thread
From: Segher Boessenkool @ 2024-02-16 13:47 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Paul Koning, gcc-patches
On Fri, Feb 16, 2024 at 11:34:55AM +0000, Maciej W. Rozycki wrote:
> Not really, in particular because EH unwinding has to be reliable and
> heuristics inherently is not.
Yup. Which is why I did 0359465c703a for rs6000 six years ago (how time
flies!) The commit message for that includes
To find out where on-entry register values live at any point in a
program, GDB currently tries to parse to parse the executable code.
This does not work very well, for example it gets confused if some
accesses to the stack use the frame pointer (r31) and some use the
stack pointer (r1). A symptom is that backtraces can be cut short.
and the patch does
+ /* By default, always emit DWARF-2 unwind info. This allows debugging
+ without maintaining a stack frame back-chain. It also allows the
+ debugger to find out where on-entry register values are stored at any
+ point in a function, without having to analyze the executable code (which
+ isn't even possible to do in the general case). */
+#ifdef OBJECT_FORMAT_ELF
+ opts->x_flag_asynchronous_unwind_tables = 1;
+#endif
We went through very many refinements of the heuristics through the
years, but at some point you just have to give up: heuristics never
can make up for missing information.
> Consequently the more aggressive the compiler has become to schedule
> function body instructions within a function's prologue the more lost the
> machine code interpreter has become. Ultimately it would have to become a
> full-fledged CPU simulator to do its heuristics.
Yup, exactly.
> In reality it means the
> unwinder may fail to produce acceptable results, which will happen at any
> frequency between hardly ever to most often, depending on the exact
> circumstances.
Yes. If the compiler optimises the *logue code well, there is no way
heuristics can follow that.
> Conversely no heuristics is required to unwind VAX frames, because they
> are fixed in layout by hardware, fully self-described, and with the
> hardware frame pointer always available.
The downside of the VAX situation of course is that the compiler has no
freedom to optimise the frame and *logue code at all, let alone well.
This may not matter so much on narrow ucoded in-order machines, there
are different balances there :-)
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2024-02-16 13:47 ` Segher Boessenkool
@ 2024-02-16 14:23 ` Maciej W. Rozycki
2024-02-16 14:31 ` Jakub Jelinek
0 siblings, 1 reply; 31+ messages in thread
From: Maciej W. Rozycki @ 2024-02-16 14:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Koning, gcc-patches
On Fri, 16 Feb 2024, Segher Boessenkool wrote:
> > Conversely no heuristics is required to unwind VAX frames, because they
> > are fixed in layout by hardware, fully self-described, and with the
> > hardware frame pointer always available.
>
> The downside of the VAX situation of course is that the compiler has no
> freedom to optimise the frame and *logue code at all, let alone well.
> This may not matter so much on narrow ucoded in-order machines, there
> are different balances there :-)
There is no function prologue to optimise in the VAX case, because all
the frame setup has already been made by the CALLS instruction itself in
the caller. The first machine instruction of the callee is technically
already past the "prologue". And then RET serves as the whole function
"epilogue".
A discussion happened at the VAX/NetBSD mailing list as to a change to
the calling convention to make it more RISC-like and replace the procedure
call (CALLS and CALLG; the latter unused in our psABI) and return (RET)
instructions with the subroutine branch (BSB), jump (JSB) and return (RSB)
instructions, which are similar in semantics to say x86 CALL (for BSB/JSB)
and RET (for RSB) instructions. Should that happen we'd have fine-grained
control over the function prologues and epilogues.
It's not clear however what the consequences such a change would have on
performance, and it would surely increase code size. And the final VAX
microarchitecture implementations (NVAX/NVAX+, dating back to 1991) have
provisions in hardware, unsurprisingly, for optimising the execution speed
of the CALL* and RET instructions.
Maciej
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-16 14:23 ` Maciej W. Rozycki
@ 2024-02-16 14:31 ` Jakub Jelinek
2024-02-16 17:01 ` Maciej W. Rozycki
0 siblings, 1 reply; 31+ messages in thread
From: Jakub Jelinek @ 2024-02-16 14:31 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Segher Boessenkool, Paul Koning, gcc-patches
On Fri, Feb 16, 2024 at 02:23:54PM +0000, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Segher Boessenkool wrote:
>
> > > Conversely no heuristics is required to unwind VAX frames, because they
> > > are fixed in layout by hardware, fully self-described, and with the
> > > hardware frame pointer always available.
> >
> > The downside of the VAX situation of course is that the compiler has no
> > freedom to optimise the frame and *logue code at all, let alone well.
> > This may not matter so much on narrow ucoded in-order machines, there
> > are different balances there :-)
>
> There is no function prologue to optimise in the VAX case, because all
> the frame setup has already been made by the CALLS instruction itself in
> the caller. The first machine instruction of the callee is technically
> already past the "prologue". And then RET serves as the whole function
> "epilogue".
So, what is the problem with DWARF unwinding? Just make sure to emit
appropriate instructions describing the saving of the corresponding
registers at specific points based on CFA at the start of the function
(so that it appears in CIE instructions) and that should be all that is
needed, no?
Jakub
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-16 14:31 ` Jakub Jelinek
@ 2024-02-16 17:01 ` Maciej W. Rozycki
2024-02-17 0:38 ` Maciej W. Rozycki
0 siblings, 1 reply; 31+ messages in thread
From: Maciej W. Rozycki @ 2024-02-16 17:01 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Segher Boessenkool, Paul Koning, gcc-patches
On Fri, 16 Feb 2024, Jakub Jelinek wrote:
> > There is no function prologue to optimise in the VAX case, because all
> > the frame setup has already been made by the CALLS instruction itself in
> > the caller. The first machine instruction of the callee is technically
> > already past the "prologue". And then RET serves as the whole function
> > "epilogue".
>
> So, what is the problem with DWARF unwinding? Just make sure to emit
> appropriate instructions describing the saving of the corresponding
> registers at specific points based on CFA at the start of the function
> (so that it appears in CIE instructions) and that should be all that is
> needed, no?
I may not remember all the issues correctly offhand as it's been a while
since I looked into it, but as I recall DWARF handling code has not been
prepared for all the frame to have been already allocated and initialised
at a function's entry point, and also at least DWARF-4 is IIRC required to
have statics at offsets positive from FP (for a stack growing downwards).
There was an issue about restoring the caller's value of SP too, which is
callee's AP+4*(*AP)+4 (AP being the argument pointer, which is a hardreg,
pointing at #arguments), or alternatively it can be calculated as the sum
of FP, the fixed frame size (20), the variable frame size (4*#statics,
recorded as a register mask in a 12-bit field at *(FP+6)), the #arguments
slot (4), and the argument space size (4*#arguments). Obviously the
former calculation is easier to make (#arguments has to be zero-extended
from bits 7:0).
FAOD the #arguments slot is filled by the CALLS instruction at call time
and can vary between callers obviously for varargs, but also cases such as
open(2), so to reconstruct the caller's SP you always need to examine the
actual stack frame, and it does not appear to be supported by libgcc DWARF
EH code as it stands.
I've left out stack realignment stuff or CALLG instruction support from
the consideration above, as we don't handle these features in our psABI,
all of which have provisions for from hardware in the stack frame.
As I say I may have missed or confused something, and anyway I'll take
another stab at it, hopefully soon.
Maciej
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-16 17:01 ` Maciej W. Rozycki
@ 2024-02-17 0:38 ` Maciej W. Rozycki
0 siblings, 0 replies; 31+ messages in thread
From: Maciej W. Rozycki @ 2024-02-17 0:38 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Segher Boessenkool, Paul Koning, gcc-patches
On Fri, 16 Feb 2024, Maciej W. Rozycki wrote:
> On Fri, 16 Feb 2024, Jakub Jelinek wrote:
>
> > > There is no function prologue to optimise in the VAX case, because all
> > > the frame setup has already been made by the CALLS instruction itself in
> > > the caller. The first machine instruction of the callee is technically
> > > already past the "prologue". And then RET serves as the whole function
> > > "epilogue".
> >
> > So, what is the problem with DWARF unwinding? Just make sure to emit
> > appropriate instructions describing the saving of the corresponding
> > registers at specific points based on CFA at the start of the function
> > (so that it appears in CIE instructions) and that should be all that is
> > needed, no?
>
> I may not remember all the issues correctly offhand as it's been a while
> since I looked into it, but as I recall DWARF handling code has not been
> prepared for all the frame to have been already allocated and initialised
> at a function's entry point, and also at least DWARF-4 is IIRC required to
> have statics at offsets positive from FP (for a stack growing downwards).
There is a further complication actually where lazy binding is in use.
In that case a function that has been jumped to indirectly from the lazy
resolver will often have a different number of statics saved in the frame
from where the function has been called directly via a fully resolved PLT
GOT entry.
This is because at the time the lazy resolver is being called it is not
known what statics the ultimate callee wants to save, as it is not a part
of the ABI. Therefore the worst condition is assumed and the resolver
requests all the statics (R6-R11) to be saved, observing that saving more
statics than required makes no change to code semantics, it just hurts
performance (but calls to the lazy resolver are rare, so this is not a big
deal). Conversely when the function has been already resolved, the PLT
GOT entry points at the callee instead, which will then only save the
statics it has requested itself, knowing them to be used.
Obviously a frame that has all the statics saved will have a different
size of its variable part and slots will have been assigned differently
there from the case where only some statics have been saved. Of course it
does not matter for regular code execution as RET will always correctly
interpret a stack frame and restore exactly these statics that have been
saved in the frame, but for unwinding actual frame contents have to be
interpreted.
I am not sure if this run-time dependent frame layout can be described in
DWARF terms even, so I am leaning towards concluding a native unwinder is
the only feasible way to go.
For those who are unaware how information as to what statics are to be
saved is made available by functions with VAX hardware: it is embedded at
the function's address in a form of a 16-bit data quantity, which is a
register save bitmask (an entry mask in VAX-speak) for registers R0-R11;
1 in the mask requests that the corresponding register be saved in the
callee's frame by the CALLS instruction. Once the frame has been built by
CALLS, control is then passed to the location immediately following the
bitmask, which is the function's actual entry point, i.e. the PC is set
to the function's address + 2.
Maciej
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2024-02-16 11:34 ` Maciej W. Rozycki
2024-02-16 13:47 ` Segher Boessenkool
@ 2024-02-16 14:50 ` Paul Koning
1 sibling, 0 replies; 31+ messages in thread
From: Paul Koning @ 2024-02-16 14:50 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Segher Boessenkool, gcc-patches
> On Feb 16, 2024, at 6:34 AM, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Thu, 15 Feb 2024, Paul Koning wrote:
>
>>> On May 15, 2023, at 5:09 PM, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>>>
>>> ...
>>>
>>> I may choose to implement a non-DWARF unwinder instead, as the VAX stack
>>> frame is always fully described by the hardware and there is never ever a
>>> need for debug information to be able to decode any VAX stack frame (the
>>> RET machine instruction uses the stack frame information to restore the
>>> previous PC, FP, SP, AP and any static registers saved by CALLS).
>>
>> That would make sense; it's like the heuristic unwinder found in some
>> other targets (I remember the MIPS one, which worked fairly well and
>> allowed debugging without useable debug data).
>
> Not really, in particular because EH unwinding has to be reliable and
> heuristics inherently is not.
Fair enough, but what I meant is only that it's conceptually similar: unwind based on the code and machine state, rather than auxiliary information like debug data. And I think your point was that on VAX this is indeed a reliable technique by virtue of the iSA. In fact, the standard way to do exeception handling unwinding is part of the originail VAX architecture (via the otherwise unused first word (I think) of the call frame).
paul
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
` (2 preceding siblings ...)
2023-04-23 18:56 ` Maciej W. Rozycki
@ 2023-04-23 21:06 ` Uros Bizjak
2023-04-24 9:17 ` Segher Boessenkool
2023-04-24 8:19 ` Richard Biener
2023-04-30 19:52 ` Jeff Law
5 siblings, 1 reply; 31+ messages in thread
From: Uros Bizjak @ 2023-04-23 21:06 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-patches
On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> This minimal patch enables LRA for all targets. It does not clean up
> the target code, nor does it do anything to generic code: it just
> deletes all target definitions of TARGET_LRA_P.
>
> There are three kinds of changes:
>
> 1) Targets that already always have LRA, but that redefine the hook
> anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).
> 2) Targets that have LRA selectable. Some of those are probably fine,
> since they default to using LRA (arc, mips, s390). Two others don't
> though, maybe because there are problems (ft32 and sh). I'd love to
> hear from all targets in this category what the status is, how easy it
> was to convert, etc.
> 3) Targets that as of yet never used LRA. Many of those will be fine,
> but some others will need a little tuning, and a few might need some
> actual improvements to LRA itself. These are cris, epiphany, fr30,
> frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
> find out how many of those targets are ever tested, and how many of
> those work with LRA without further changes, and how well.
>
> I send this patch now so that people can start testing. I don't plan to
> commit this for another week at least, for a week after GCC 13 release I
> guess? How does that plan sound to people?
An old patch to enable Alpha is at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207
Uros.
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-23 21:06 ` Uros Bizjak
@ 2023-04-24 9:17 ` Segher Boessenkool
2023-04-24 9:46 ` Uros Bizjak
0 siblings, 1 reply; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-24 9:17 UTC (permalink / raw)
To: Uros Bizjak; +Cc: gcc-patches
On Sun, Apr 23, 2023 at 11:06:41PM +0200, Uros Bizjak wrote:
> > I send this patch now so that people can start testing. I don't plan to
> > commit this for another week at least, for a week after GCC 13 release I
> > guess? How does that plan sound to people?
>
> An old patch to enable Alpha is at
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207
Ah, good to hear it worked way back then already!
We still need someone to test this on alpha now, years later, and give
a final okay, but hearing this is encouraging :-)
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-24 9:17 ` Segher Boessenkool
@ 2023-04-24 9:46 ` Uros Bizjak
2023-04-29 14:38 ` Segher Boessenkool
0 siblings, 1 reply; 31+ messages in thread
From: Uros Bizjak @ 2023-04-24 9:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-patches
On Mon, Apr 24, 2023 at 11:19 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sun, Apr 23, 2023 at 11:06:41PM +0200, Uros Bizjak wrote:
> > > I send this patch now so that people can start testing. I don't plan to
> > > commit this for another week at least, for a week after GCC 13 release I
> > > guess? How does that plan sound to people?
> >
> > An old patch to enable Alpha is at
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207
>
> Ah, good to hear it worked way back then already!
>
> We still need someone to test this on alpha now, years later, and give
> a final okay, but hearing this is encouraging :-)
Please note that bootstrap worked on alpha*EV6*, not plain alpha.
Plain alpha is !BWX architecture and uses {un,}aligned_memory_operand
predicates that call resolve_reload_operand function. Unfortunately,
this function peeks deep into reload internals (reg_equiv_memory_loc)
that has no equivalent in LRA. As said in the comment, this internal
function resolves what reload is going to do with OP if it is a
register.
Uros.
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-24 9:46 ` Uros Bizjak
@ 2023-04-29 14:38 ` Segher Boessenkool
0 siblings, 0 replies; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-29 14:38 UTC (permalink / raw)
To: Uros Bizjak; +Cc: gcc-patches
Hi!
On Mon, Apr 24, 2023 at 11:46:50AM +0200, Uros Bizjak wrote:
> On Mon, Apr 24, 2023 at 11:19 AM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > We still need someone to test this on alpha now, years later, and give
> > a final okay, but hearing this is encouraging :-)
>
> Please note that bootstrap worked on alpha*EV6*, not plain alpha.
>
> Plain alpha is !BWX architecture and uses {un,}aligned_memory_operand
> predicates that call resolve_reload_operand function. Unfortunately,
> this function peeks deep into reload internals (reg_equiv_memory_loc)
> that has no equivalent in LRA. As said in the comment, this internal
> function resolves what reload is going to do with OP if it is a
> register.
Bootstrap works with everything I tried, but building Linux fails with a
few things like
/home/segher/src/kernel/drivers/tty/serial/serial_core.c:1029:1: internal compiler error: maximum number of generated reload insns per insn achieved (90)
(it uses -mcpu=ev5 there; to reproduce just (try to) build a defconfig).
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
` (3 preceding siblings ...)
2023-04-23 21:06 ` Uros Bizjak
@ 2023-04-24 8:19 ` Richard Biener
2023-04-24 9:44 ` Segher Boessenkool
2023-04-30 19:52 ` Jeff Law
5 siblings, 1 reply; 31+ messages in thread
From: Richard Biener @ 2023-04-24 8:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: gcc-patches
On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> This minimal patch enables LRA for all targets. It does not clean up
> the target code, nor does it do anything to generic code: it just
> deletes all target definitions of TARGET_LRA_P.
>
> There are three kinds of changes:
>
> 1) Targets that already always have LRA, but that redefine the hook
> anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).
> 2) Targets that have LRA selectable. Some of those are probably fine,
> since they default to using LRA (arc, mips, s390). Two others don't
> though, maybe because there are problems (ft32 and sh). I'd love to
> hear from all targets in this category what the status is, how easy it
> was to convert, etc.
I think 1) and 2) where the default is LRA already should be changed to
use the existing default and the ability to switch back to reload removed.
That could be done independently and soon.
> 3) Targets that as of yet never used LRA. Many of those will be fine,
> but some others will need a little tuning, and a few might need some
> actual improvements to LRA itself. These are cris, epiphany, fr30,
> frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
> find out how many of those targets are ever tested, and how many of
> those work with LRA without further changes, and how well.
>
> I send this patch now so that people can start testing. I don't plan to
> commit this for another week at least, for a week after GCC 13 release I
> guess? How does that plan sound to people?
I think it's important to check that the targets still build, including a
sensible set of their target libraries in a sensible set of their
multilib configurations so they are not completely cut off from
testing.
"Converting" targets one-by-one this way is sensible and appreciated.
>
> This is an RFC, so no changelog, no one can accidentally commit it :-)
> I thought about Cc:ing lots and lots of people, should I do that?
Did we announce a cut-off for reload going away? Knowing the set of
targets that fail to "auto-convert" within the above constraint would be
nice.
Thanks for pushing!
Richard.
>
>
> Segher
> ---
> gcc/config/alpha/alpha.cc | 3 ---
> gcc/config/arc/arc.cc | 2 --
> gcc/config/avr/avr.cc | 3 ---
> gcc/config/bfin/bfin.cc | 3 ---
> gcc/config/c6x/c6x.cc | 3 ---
> gcc/config/cris/cris.cc | 3 ---
> gcc/config/epiphany/epiphany.cc | 2 --
> gcc/config/fr30/fr30.cc | 3 ---
> gcc/config/frv/frv.cc | 3 ---
> gcc/config/ft32/ft32.cc | 3 ---
> gcc/config/gcn/gcn.cc | 2 --
> gcc/config/h8300/h8300.cc | 3 ---
> gcc/config/ia64/ia64.cc | 3 ---
> gcc/config/iq2000/iq2000.cc | 3 ---
> gcc/config/lm32/lm32.cc | 2 --
> gcc/config/m32c/m32c.cc | 3 ---
> gcc/config/m32r/m32r.cc | 3 ---
> gcc/config/m68k/m68k.cc | 3 ---
> gcc/config/mcore/mcore.cc | 3 ---
> gcc/config/microblaze/microblaze.cc | 3 ---
> gcc/config/mips/mips.cc | 2 --
> gcc/config/mmix/mmix.cc | 3 ---
> gcc/config/mn10300/mn10300.cc | 3 ---
> gcc/config/msp430/msp430.cc | 3 ---
> gcc/config/nvptx/nvptx.cc | 3 ---
> gcc/config/pa/pa.cc | 3 ---
> gcc/config/pdp11/pdp11.cc | 3 ---
> gcc/config/rl78/rl78.cc | 3 ---
> gcc/config/rx/rx.cc | 3 ---
> gcc/config/s390/s390.cc | 3 ---
> gcc/config/sh/sh.cc | 3 ---
> gcc/config/sparc/sparc.cc | 3 ---
> gcc/config/stormy16/stormy16.cc | 3 ---
> gcc/config/vax/vax.cc | 3 ---
> gcc/config/visium/visium.cc | 3 ---
> gcc/config/xtensa/xtensa.cc | 3 ---
> 36 files changed, 103 deletions(-)
>
> diff --git a/gcc/config/alpha/alpha.cc b/gcc/config/alpha/alpha.cc
> index 1d826085198e..784348dbe787 100644
> --- a/gcc/config/alpha/alpha.cc
> +++ b/gcc/config/alpha/alpha.cc
> @@ -10094,9 +10094,6 @@ alpha_can_change_mode_class (machine_mode from, machine_mode to,
> #define TARGET_MANGLE_TYPE alpha_mangle_type
> #endif
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p
>
> diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
> index 22eb2e9cb459..8cd5a794073f 100644
> --- a/gcc/config/arc/arc.cc
> +++ b/gcc/config/arc/arc.cc
> @@ -804,8 +804,6 @@ static rtx arc_legitimize_address_0 (rtx, rtx, machine_mode mode);
> #define TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P \
> arc_no_speculation_in_delay_slots_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P arc_lra_p
> #define TARGET_REGISTER_PRIORITY arc_register_priority
> /* Stores with scaled offsets have different displacement ranges. */
> #define TARGET_DIFFERENT_ADDR_DISPLACEMENT_P hook_bool_void_true
> diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
> index c193430cf073..f2a075381d47 100644
> --- a/gcc/config/avr/avr.cc
> +++ b/gcc/config/avr/avr.cc
> @@ -14663,9 +14663,6 @@ avr_float_lib_compare_returns_bool (machine_mode mode, enum rtx_code)
> #undef TARGET_CONVERT_TO_TYPE
> #define TARGET_CONVERT_TO_TYPE avr_convert_to_type
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_ADDR_SPACE_SUBSET_P
> #define TARGET_ADDR_SPACE_SUBSET_P avr_addr_space_subset_p
>
> diff --git a/gcc/config/bfin/bfin.cc b/gcc/config/bfin/bfin.cc
> index c70d2281f068..565f817d2e77 100644
> --- a/gcc/config/bfin/bfin.cc
> +++ b/gcc/config/bfin/bfin.cc
> @@ -5834,9 +5834,6 @@ bfin_conditional_register_usage (void)
> #undef TARGET_RETURN_IN_MEMORY
> #define TARGET_RETURN_IN_MEMORY bfin_return_in_memory
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P bfin_legitimate_address_p
>
> diff --git a/gcc/config/c6x/c6x.cc b/gcc/config/c6x/c6x.cc
> index 15be3b23716b..f4c1af1ab7c3 100644
> --- a/gcc/config/c6x/c6x.cc
> +++ b/gcc/config/c6x/c6x.cc
> @@ -6751,9 +6751,6 @@ c6x_regno_reg_class (int reg)
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P c6x_legitimate_address_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_IN_SMALL_DATA_P
> #define TARGET_IN_SMALL_DATA_P c6x_in_small_data_p
> #undef TARGET_ASM_SELECT_RTX_SECTION
> diff --git a/gcc/config/cris/cris.cc b/gcc/config/cris/cris.cc
> index 05dead9c0778..7ce1b754e76e 100644
> --- a/gcc/config/cris/cris.cc
> +++ b/gcc/config/cris/cris.cc
> @@ -215,9 +215,6 @@ int cris_cpu_version = CRIS_DEFAULT_CPU_VERSION;
> #undef TARGET_INIT_LIBFUNCS
> #define TARGET_INIT_LIBFUNCS cris_init_libfuncs
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P cris_legitimate_address_p
>
> diff --git a/gcc/config/epiphany/epiphany.cc b/gcc/config/epiphany/epiphany.cc
> index fdd4df71456b..20c20e18ea0f 100644
> --- a/gcc/config/epiphany/epiphany.cc
> +++ b/gcc/config/epiphany/epiphany.cc
> @@ -106,8 +106,6 @@ static rtx_insn *frame_insn (rtx);
> #define TARGET_SCHED_ISSUE_RATE epiphany_issue_rate
> #define TARGET_SCHED_ADJUST_COST epiphany_adjust_cost
>
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #define TARGET_LEGITIMATE_ADDRESS_P epiphany_legitimate_address_p
>
> #define TARGET_SECONDARY_RELOAD epiphany_secondary_reload
> diff --git a/gcc/config/fr30/fr30.cc b/gcc/config/fr30/fr30.cc
> index 0d05b13aa31e..d2b2bf39c7f9 100644
> --- a/gcc/config/fr30/fr30.cc
> +++ b/gcc/config/fr30/fr30.cc
> @@ -185,9 +185,6 @@ static int fr30_num_arg_regs (const function_arg_info &);
> #undef TARGET_CAN_ELIMINATE
> #define TARGET_CAN_ELIMINATE fr30_can_eliminate
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_ASM_TRAMPOLINE_TEMPLATE
> #define TARGET_ASM_TRAMPOLINE_TEMPLATE fr30_asm_trampoline_template
> #undef TARGET_TRAMPOLINE_INIT
> diff --git a/gcc/config/frv/frv.cc b/gcc/config/frv/frv.cc
> index 99f79325cd6f..71f6d92e2abb 100644
> --- a/gcc/config/frv/frv.cc
> +++ b/gcc/config/frv/frv.cc
> @@ -496,9 +496,6 @@ static bool frv_modes_tieable_p (machine_mode, machine_mode);
> #undef TARGET_SECONDARY_RELOAD
> #define TARGET_SECONDARY_RELOAD frv_secondary_reload
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P frv_legitimate_address_p
>
> diff --git a/gcc/config/ft32/ft32.cc b/gcc/config/ft32/ft32.cc
> index 806ab769f795..dfca7883ab65 100644
> --- a/gcc/config/ft32/ft32.cc
> +++ b/gcc/config/ft32/ft32.cc
> @@ -840,9 +840,6 @@ ft32_lra_p (void)
> return ft32_lra_flag;
> }
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P ft32_lra_p
> -
> static bool
> reg_ok_for_base_p (rtx r, bool strict)
> {
> diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
> index 5608d85a1a07..d2f92e50bc6e 100644
> --- a/gcc/config/gcn/gcn.cc
> +++ b/gcc/config/gcn/gcn.cc
> @@ -7510,8 +7510,6 @@ gcn_dwarf_register_span (rtx rtl)
> #define TARGET_LEGITIMATE_CONSTANT_P gcn_legitimate_constant_p
> #undef TARGET_LIBC_HAS_FUNCTION
> #define TARGET_LIBC_HAS_FUNCTION gcn_libc_has_function
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_true
> #undef TARGET_MACHINE_DEPENDENT_REORG
> #define TARGET_MACHINE_DEPENDENT_REORG gcn_md_reorg
> #undef TARGET_MEMORY_MOVE_COST
> diff --git a/gcc/config/h8300/h8300.cc b/gcc/config/h8300/h8300.cc
> index c3674933f900..815267393cb1 100644
> --- a/gcc/config/h8300/h8300.cc
> +++ b/gcc/config/h8300/h8300.cc
> @@ -5625,9 +5625,6 @@ pre_incdec_with_reg (rtx op, unsigned int reg)
> #undef TARGET_MODES_TIEABLE_P
> #define TARGET_MODES_TIEABLE_P h8300_modes_tieable_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P h8300_legitimate_address_p
>
> diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc
> index f32efb3bd803..dd11709072e5 100644
> --- a/gcc/config/ia64/ia64.cc
> +++ b/gcc/config/ia64/ia64.cc
> @@ -608,9 +608,6 @@ static const struct attribute_spec ia64_attribute_table[] =
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_CANNOT_FORCE_CONST_MEM
> #define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem
>
> diff --git a/gcc/config/iq2000/iq2000.cc b/gcc/config/iq2000/iq2000.cc
> index de44d361080b..067154a0a0d9 100644
> --- a/gcc/config/iq2000/iq2000.cc
> +++ b/gcc/config/iq2000/iq2000.cc
> @@ -241,9 +241,6 @@ static HOST_WIDE_INT iq2000_starting_frame_offset (void);
> #undef TARGET_EXPAND_BUILTIN_VA_START
> #define TARGET_EXPAND_BUILTIN_VA_START iq2000_va_start
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P iq2000_legitimate_address_p
>
> diff --git a/gcc/config/lm32/lm32.cc b/gcc/config/lm32/lm32.cc
> index 37a6eb86da05..3f1d9d388993 100644
> --- a/gcc/config/lm32/lm32.cc
> +++ b/gcc/config/lm32/lm32.cc
> @@ -104,8 +104,6 @@ static HOST_WIDE_INT lm32_starting_frame_offset (void);
> #define TARGET_MAX_ANCHOR_OFFSET 0x7fff
> #undef TARGET_CAN_ELIMINATE
> #define TARGET_CAN_ELIMINATE lm32_can_eliminate
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P lm32_legitimate_address_p
> #undef TARGET_HARD_REGNO_MODE_OK
> diff --git a/gcc/config/m32c/m32c.cc b/gcc/config/m32c/m32c.cc
> index e0d06f833d3d..691014f52232 100644
> --- a/gcc/config/m32c/m32c.cc
> +++ b/gcc/config/m32c/m32c.cc
> @@ -1636,9 +1636,6 @@ m32c_trampoline_init (rtx m_tramp, tree fndecl, rtx chainval)
> #undef A0
> }
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> /* Addressing Modes */
>
> /* The r8c/m32c family supports a wide range of non-orthogonal
> diff --git a/gcc/config/m32r/m32r.cc b/gcc/config/m32r/m32r.cc
> index 5a788e295154..155a248459bc 100644
> --- a/gcc/config/m32r/m32r.cc
> +++ b/gcc/config/m32r/m32r.cc
> @@ -127,9 +127,6 @@ static const struct attribute_spec m32r_attribute_table[] =
> #undef TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P
> #define TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P m32r_attribute_identifier
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P m32r_legitimate_address_p
> #undef TARGET_LEGITIMIZE_ADDRESS
> diff --git a/gcc/config/m68k/m68k.cc b/gcc/config/m68k/m68k.cc
> index 03db2b6a9369..64e7d3bca620 100644
> --- a/gcc/config/m68k/m68k.cc
> +++ b/gcc/config/m68k/m68k.cc
> @@ -303,9 +303,6 @@ static void m68k_asm_final_postscan_insn (FILE *, rtx_insn *insn, rtx [], int);
> #define TARGET_ASM_OUTPUT_DWARF_DTPREL m68k_output_dwarf_dtprel
> #endif
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P m68k_legitimate_address_p
>
> diff --git a/gcc/config/mcore/mcore.cc b/gcc/config/mcore/mcore.cc
> index e800af78e14b..384d702ed77f 100644
> --- a/gcc/config/mcore/mcore.cc
> +++ b/gcc/config/mcore/mcore.cc
> @@ -237,9 +237,6 @@ static const struct attribute_spec mcore_attribute_table[] =
> #undef TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
> #define TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P mcore_legitimate_address_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_WARN_FUNC_RETURN
> #define TARGET_WARN_FUNC_RETURN mcore_warn_func_return
>
> diff --git a/gcc/config/microblaze/microblaze.cc b/gcc/config/microblaze/microblaze.cc
> index 6df2c712cab1..ebe78304f898 100644
> --- a/gcc/config/microblaze/microblaze.cc
> +++ b/gcc/config/microblaze/microblaze.cc
> @@ -4017,9 +4017,6 @@ microblaze_starting_frame_offset (void)
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P microblaze_legitimate_address_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_FRAME_POINTER_REQUIRED
> #define TARGET_FRAME_POINTER_REQUIRED microblaze_frame_pointer_required
>
> diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> index ca822758b41c..b5e225896da9 100644
> --- a/gcc/config/mips/mips.cc
> +++ b/gcc/config/mips/mips.cc
> @@ -23011,8 +23011,6 @@ mips_asm_file_end (void)
>
> #undef TARGET_SPILL_CLASS
> #define TARGET_SPILL_CLASS mips_spill_class
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P mips_lra_p
> #undef TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
> #define TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS mips_ira_change_pseudo_allocno_class
>
> diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
> index 4e4fb8bdac27..eda2959adb96 100644
> --- a/gcc/config/mmix/mmix.cc
> +++ b/gcc/config/mmix/mmix.cc
> @@ -273,9 +273,6 @@ static HOST_WIDE_INT mmix_starting_frame_offset (void);
> #undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
> #define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS mmix_preferred_output_reload_class
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P mmix_legitimate_address_p
> #undef TARGET_LEGITIMATE_CONSTANT_P
> diff --git a/gcc/config/mn10300/mn10300.cc b/gcc/config/mn10300/mn10300.cc
> index a8b01a543cc7..4540858d312e 100644
> --- a/gcc/config/mn10300/mn10300.cc
> +++ b/gcc/config/mn10300/mn10300.cc
> @@ -3368,9 +3368,6 @@ mn10300_reorg (void)
> #undef TARGET_CASE_VALUES_THRESHOLD
> #define TARGET_CASE_VALUES_THRESHOLD mn10300_case_values_threshold
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P mn10300_legitimate_address_p
> #undef TARGET_DELEGITIMIZE_ADDRESS
> diff --git a/gcc/config/msp430/msp430.cc b/gcc/config/msp430/msp430.cc
> index 6f9c56187ee3..1af0223cb394 100644
> --- a/gcc/config/msp430/msp430.cc
> +++ b/gcc/config/msp430/msp430.cc
> @@ -902,9 +902,6 @@ msp430_gimplify_va_arg_expr (tree valist, tree type, gimple_seq *pre_p,
> return addr;
> }
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> /* Addressing Modes */
>
> #undef TARGET_LEGITIMATE_ADDRESS_P
> diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
> index 89349dae9e62..e32f17377525 100644
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvptx/nvptx.cc
> @@ -7601,9 +7601,6 @@ nvptx_asm_output_def_from_decls (FILE *stream, tree name, tree value)
> #undef TARGET_ATTRIBUTE_TABLE
> #define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P nvptx_legitimate_address_p
>
> diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
> index db633b275e5e..2198140cb492 100644
> --- a/gcc/config/pa/pa.cc
> +++ b/gcc/config/pa/pa.cc
> @@ -403,9 +403,6 @@ static size_t n_deferred_plabels = 0;
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P pa_legitimate_address_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_HARD_REGNO_NREGS
> #define TARGET_HARD_REGNO_NREGS pa_hard_regno_nregs
> #undef TARGET_HARD_REGNO_MODE_OK
> diff --git a/gcc/config/pdp11/pdp11.cc b/gcc/config/pdp11/pdp11.cc
> index 4af26f8cd709..528dfd59a770 100644
> --- a/gcc/config/pdp11/pdp11.cc
> +++ b/gcc/config/pdp11/pdp11.cc
> @@ -228,9 +228,6 @@ static bool pdp11_scalar_mode_supported_p (scalar_mode);
> #undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
> #define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS pdp11_preferred_output_reload_class
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P pdp11_lra_p
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P pdp11_legitimate_address_p
>
> diff --git a/gcc/config/rl78/rl78.cc b/gcc/config/rl78/rl78.cc
> index 7ed28d35883a..440eb134b349 100644
> --- a/gcc/config/rl78/rl78.cc
> +++ b/gcc/config/rl78/rl78.cc
> @@ -1135,9 +1135,6 @@ rl78_is_legitimate_constant (machine_mode mode ATTRIBUTE_UNUSED, rtx x ATTRIBUTE
> return true;
> }
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
> #define TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P rl78_as_legitimate_address
>
> diff --git a/gcc/config/rx/rx.cc b/gcc/config/rx/rx.cc
> index 726b00a3193b..64a30963e7f5 100644
> --- a/gcc/config/rx/rx.cc
> +++ b/gcc/config/rx/rx.cc
> @@ -3790,9 +3790,6 @@ rx_modes_tieable_p (machine_mode mode1, machine_mode mode2)
> #undef TARGET_WARN_FUNC_RETURN
> #define TARGET_WARN_FUNC_RETURN rx_warn_func_return
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P rx_enable_lra
> -
> #undef TARGET_HARD_REGNO_NREGS
> #define TARGET_HARD_REGNO_NREGS rx_hard_regno_nregs
> #undef TARGET_HARD_REGNO_MODE_OK
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 505de995da87..639c1e483003 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -17706,9 +17706,6 @@ s390_vectorize_vec_perm_const (machine_mode vmode, machine_mode op_mode,
> #undef TARGET_LEGITIMATE_CONSTANT_P
> #define TARGET_LEGITIMATE_CONSTANT_P s390_legitimate_constant_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P s390_lra_p
> -
> #undef TARGET_CAN_ELIMINATE
> #define TARGET_CAN_ELIMINATE s390_can_eliminate
>
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index cf6188bd19db..fae58b3e574a 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -593,9 +593,6 @@ static const struct attribute_spec sh_attribute_table[] =
> #undef TARGET_ENCODE_SECTION_INFO
> #define TARGET_ENCODE_SECTION_INFO sh_encode_section_info
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P sh_lra_p
> -
> #undef TARGET_SECONDARY_RELOAD
> #define TARGET_SECONDARY_RELOAD sh_secondary_reload
>
> diff --git a/gcc/config/sparc/sparc.cc b/gcc/config/sparc/sparc.cc
> index 8c0c9dce9714..48204ffaf625 100644
> --- a/gcc/config/sparc/sparc.cc
> +++ b/gcc/config/sparc/sparc.cc
> @@ -910,9 +910,6 @@ char sparc_hard_reg_printed[8];
> #define TARGET_MANGLE_TYPE sparc_mangle_type
> #endif
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P sparc_lra_p
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P sparc_legitimate_address_p
>
> diff --git a/gcc/config/stormy16/stormy16.cc b/gcc/config/stormy16/stormy16.cc
> index 1ed619a28968..4bfe846fc8ce 100644
> --- a/gcc/config/stormy16/stormy16.cc
> +++ b/gcc/config/stormy16/stormy16.cc
> @@ -2719,9 +2719,6 @@ xstormy16_push_rounding (poly_int64 bytes)
> #undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
> #define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS xstormy16_preferred_reload_class
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P xstormy16_legitimate_address_p
> #undef TARGET_MODE_DEPENDENT_ADDRESS_P
> diff --git a/gcc/config/vax/vax.cc b/gcc/config/vax/vax.cc
> index 82a176d3bfc9..17fdc4483797 100644
> --- a/gcc/config/vax/vax.cc
> +++ b/gcc/config/vax/vax.cc
> @@ -114,9 +114,6 @@ static HOST_WIDE_INT vax_starting_frame_offset (void);
> #undef TARGET_STRUCT_VALUE_RTX
> #define TARGET_STRUCT_VALUE_RTX vax_struct_value_rtx
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P vax_lra_p
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P vax_legitimate_address_p
> #undef TARGET_MODE_DEPENDENT_ADDRESS_P
> diff --git a/gcc/config/visium/visium.cc b/gcc/config/visium/visium.cc
> index ec4c2e9ae5cb..c727b5d6d29d 100644
> --- a/gcc/config/visium/visium.cc
> +++ b/gcc/config/visium/visium.cc
> @@ -280,9 +280,6 @@ static HOST_WIDE_INT visium_constant_alignment (const_tree, HOST_WIDE_INT);
> #undef TARGET_LEGITIMATE_CONSTANT_P
> #define TARGET_LEGITIMATE_CONSTANT_P visium_legitimate_constant_p
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P hook_bool_void_false
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P visium_legitimate_address_p
>
> diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
> index 9e5d314e143e..4c98f3071c4d 100644
> --- a/gcc/config/xtensa/xtensa.cc
> +++ b/gcc/config/xtensa/xtensa.cc
> @@ -286,9 +286,6 @@ static rtx xtensa_delegitimize_address (rtx);
> #undef TARGET_CANNOT_FORCE_CONST_MEM
> #define TARGET_CANNOT_FORCE_CONST_MEM xtensa_cannot_force_const_mem
>
> -#undef TARGET_LRA_P
> -#define TARGET_LRA_P xtensa_lra_p
> -
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P xtensa_legitimate_address_p
>
> --
> 1.8.3.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [PATCH] Turn on LRA on all targets
2023-04-24 8:19 ` Richard Biener
@ 2023-04-24 9:44 ` Segher Boessenkool
0 siblings, 0 replies; 31+ messages in thread
From: Segher Boessenkool @ 2023-04-24 9:44 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
On Mon, Apr 24, 2023 at 10:19:23AM +0200, Richard Biener wrote:
> On Sun, Apr 23, 2023 at 6:48 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > This minimal patch enables LRA for all targets. It does not clean up
> > the target code, nor does it do anything to generic code: it just
> > deletes all target definitions of TARGET_LRA_P.
> >
> > There are three kinds of changes:
> >
> > 1) Targets that already always have LRA, but that redefine the hook
> > anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> > really changes for these targets with this patch (but later patches
> > will delete the superfluous hook implementations).
> > 2) Targets that have LRA selectable. Some of those are probably fine,
> > since they default to using LRA (arc, mips, s390). Two others don't
> > though, maybe because there are problems (ft32 and sh). I'd love to
> > hear from all targets in this category what the status is, how easy it
> > was to convert, etc.
(Note I misqualified a bunch under 1) that should be 2)).
> I think 1) and 2) where the default is LRA already should be changed to
> use the existing default and the ability to switch back to reload removed.
> That could be done independently and soon.
Sure. Those categories of backends are easy to handle anyway. Cat. 3
is the problematic category.
> > 3) Targets that as of yet never used LRA. Many of those will be fine,
> > but some others will need a little tuning, and a few might need some
> > actual improvements to LRA itself. These are cris, epiphany, fr30,
> > frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> > mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
> > find out how many of those targets are ever tested, and how many of
> > those work with LRA without further changes, and how well.
> >
> > I send this patch now so that people can start testing. I don't plan to
> > commit this for another week at least, for a week after GCC 13 release I
> > guess? How does that plan sound to people?
>
> I think it's important to check that the targets still build, including a
> sensible set of their target libraries in a sensible set of their
> multilib configurations so they are not completely cut off from
> testing.
>
> "Converting" targets one-by-one this way is sensible and appreciated.
Yes. I sent this all-in-one simple-to-apply simple-to-test RFC patch
to try and get things moving, especially for all those targets where all
previous attempts have done nothing.
> > This is an RFC, so no changelog, no one can accidentally commit it :-)
> > I thought about Cc:ing lots and lots of people, should I do that?
>
> Did we announce a cut-off for reload going away?
I tried to do that in <https://inbox.sourceware.org/gcc-patches/febe8136ba2e1afbbf70beff8ce0a1cf66401dff.1672946731.git.segher@kernel.crashing.org/>
but it was decided we should not announce this in user documentation.
There has been talk about this on the developer mailing lists (and
elsewhere, irc for example) for ages, so it shouldn't come as a surprise
to anyone.
> Knowing the set of
> targets that fail to "auto-convert" within the above constraint would be
> nice.
Yes, but the response from most of the category 3 targets has been
thunderous silence :-/
I'll test how many targets fall down at my boring "build Linux" (so, the
kernel, not a distro :-) ) test, already. A bit scared of doing that,
but it is time I guess.
> Thanks for pushing!
"It's a dirty job", etc.
So many ancient shortcomings of GCC cannot reasonably be solved while we
still allow old reload to be used (subregs of mem anyone? But that is
just one example). Let's see where this goes!
Segher
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
` (4 preceding siblings ...)
2023-04-24 8:19 ` Richard Biener
@ 2023-04-30 19:52 ` Jeff Law
5 siblings, 0 replies; 31+ messages in thread
From: Jeff Law @ 2023-04-30 19:52 UTC (permalink / raw)
To: gcc-patches
On 4/23/23 10:47, Segher Boessenkool wrote:
> This minimal patch enables LRA for all targets. It does not clean up
> the target code, nor does it do anything to generic code: it just
> deletes all target definitions of TARGET_LRA_P.
>
> There are three kinds of changes:
>
> 1) Targets that already always have LRA, but that redefine the hook
> anyway. These are gcn, pdp11, rx, sparc, vax, and xtensa. Nothing
> really changes for these targets with this patch (but later patches
> will delete the superfluous hook implementations).
> 2) Targets that have LRA selectable. Some of those are probably fine,
> since they default to using LRA (arc, mips, s390). Two others don't
> though, maybe because there are problems (ft32 and sh). I'd love to
> hear from all targets in this category what the status is, how easy it
> was to convert, etc.
> 3) Targets that as of yet never used LRA. Many of those will be fine,
> but some others will need a little tuning, and a few might need some
> actual improvements to LRA itself. These are cris, epiphany, fr30,
> frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
> mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium. We'll
> find out how many of those targets are ever tested, and how many of
> those work with LRA without further changes, and how well.
>
> I send this patch now so that people can start testing. I don't plan to
> commit this for another week at least, for a week after GCC 13 release I
> guess? How does that plan sound to people?
>
> This is an RFC, so no changelog, no one can accidentally commit it :-)
> I thought about Cc:ing lots and lots of people, should I do that?ISTM that we ought to go through the non-LRA targets one by one to see
which can be trivially converted and will still work. Any that meet
that criteria should just be converted.
While we may have some performance deltas, I would argue we just move
forward. The maintainers can and should be participating in getting us
moved away from reload.
Of the list you mentioned, I would just remove m32c. It hasn't been
able to even build newlib in years and while I did spend some time
debugging it, my conclusion was it was not salvagable. It should just
be deprecated.
For epiphany, it faults semi-randomly in reload last I looked and I
haven't even tried to have the tester build newlib on that platform in
eons. I think epiphany should be deprecated as well.
Jeff
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
@ 2023-04-29 13:37 Roger Sayle
2023-04-29 15:06 ` Jeff Law
0 siblings, 1 reply; 31+ messages in thread
From: Roger Sayle @ 2023-04-29 13:37 UTC (permalink / raw)
To: 'GCC Patches'
Cc: 'Segher Boessenkool', 'Tom de Vries'
Segher Boessenkool wrote:
> I send this patch now so that people can start testing.
>
> diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
> index 89349dae9e62..e32f17377525 100644
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvptx/nvptx.cc
> @@ -7601,9 +7601,6 @@ nvptx_asm_output_def_from_decls (FILE *stream, tree
name, tree value)
> #undef TARGET_ATTRIBUTE_TABLE
> #define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
>
>-#undef TARGET_LRA_P
>-#define TARGET_LRA_P hook_bool_void_false
>-
> #undef TARGET_LEGITIMATE_ADDRESS_P
> #define TARGET_LEGITIMATE_ADDRESS_P nvptx_legitimate_address_p
I've tested Segher's patch on nvptx-none with make and make -k check and
can confirm there are no new regressions. Nvptx is unique in that it
doesn't
use register allocation, i.e. GCC's only TARGET_NO_REGISTER_ALLOCATION
target,
so it's a little odd that it specifies which register allocator it doesn't
use.
I hope this helps,
Roger
--
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH] Turn on LRA on all targets
2023-04-29 13:37 Roger Sayle
@ 2023-04-29 15:06 ` Jeff Law
0 siblings, 0 replies; 31+ messages in thread
From: Jeff Law @ 2023-04-29 15:06 UTC (permalink / raw)
To: Roger Sayle, 'GCC Patches'
Cc: 'Segher Boessenkool', 'Tom de Vries'
On 4/29/23 07:37, Roger Sayle wrote:
>
> Segher Boessenkool wrote:
>> I send this patch now so that people can start testing.
>>
>> diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
>> index 89349dae9e62..e32f17377525 100644
>> --- a/gcc/config/nvptx/nvptx.cc
>> +++ b/gcc/config/nvptx/nvptx.cc
>> @@ -7601,9 +7601,6 @@ nvptx_asm_output_def_from_decls (FILE *stream, tree
> name, tree value)
>> #undef TARGET_ATTRIBUTE_TABLE
>> #define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
>>
>> -#undef TARGET_LRA_P
>> -#define TARGET_LRA_P hook_bool_void_false
>> -
>> #undef TARGET_LEGITIMATE_ADDRESS_P
>> #define TARGET_LEGITIMATE_ADDRESS_P nvptx_legitimate_address_p
>
>
> I've tested Segher's patch on nvptx-none with make and make -k check and
> can confirm there are no new regressions. Nvptx is unique in that it
> doesn't
> use register allocation, i.e. GCC's only TARGET_NO_REGISTER_ALLOCATION
> target,
> so it's a little odd that it specifies which register allocator it doesn't
> use.
>
> I hope this helps,
It does. Consider a patch which flips the nvptx port to LRA as
pre-approved.
I tried the FRV just for fun. It faulted all over the place :(
jeff
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2024-02-17 0:38 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-23 16:47 [PATCH] Turn on LRA on all targets Segher Boessenkool
2023-04-23 17:01 ` Jeff Law
2023-04-23 20:23 ` Segher Boessenkool
2023-04-24 8:42 ` Andreas Schwab
2023-04-23 18:36 ` Paul Koning
2023-04-23 20:19 ` Segher Boessenkool
2023-04-23 18:56 ` Maciej W. Rozycki
2023-04-23 20:33 ` Segher Boessenkool
2023-05-15 21:09 ` Maciej W. Rozycki
2023-05-15 21:16 ` Sam James
2024-02-15 19:34 ` Sam James
2024-02-15 22:56 ` Segher Boessenkool
2024-02-16 1:41 ` Paul Koning
2024-02-16 10:22 ` Segher Boessenkool
2024-02-15 22:21 ` Paul Koning
2024-02-16 11:34 ` Maciej W. Rozycki
2024-02-16 13:47 ` Segher Boessenkool
2024-02-16 14:23 ` Maciej W. Rozycki
2024-02-16 14:31 ` Jakub Jelinek
2024-02-16 17:01 ` Maciej W. Rozycki
2024-02-17 0:38 ` Maciej W. Rozycki
2024-02-16 14:50 ` Paul Koning
2023-04-23 21:06 ` Uros Bizjak
2023-04-24 9:17 ` Segher Boessenkool
2023-04-24 9:46 ` Uros Bizjak
2023-04-29 14:38 ` Segher Boessenkool
2023-04-24 8:19 ` Richard Biener
2023-04-24 9:44 ` Segher Boessenkool
2023-04-30 19:52 ` Jeff Law
2023-04-29 13:37 Roger Sayle
2023-04-29 15:06 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).