Hi H-P, This patch should now already be on trunk: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2 b27953c8cd Many thanks to Jeff for the review/approval. There have been no reported adverse effects so far. Please let me/us know if this has helped CRIS.
Cheers, Roger -- -----Original Message----- From: Hans-Peter Nilsson <h...@axis.com> Sent: 12 May 2023 14:54 To: Hans-Peter Nilsson <h...@axis.com> Cc: ro...@nextmovesoftware.com; jeffreya...@gmail.com; gcc-patches@gcc.gnu.org; seg...@kernel.crashing.org Subject: Re: [committed] Convert xstormy16 to LRA > From: Hans-Peter Nilsson <h...@axis.com> > Date: Thu, 11 May 2023 17:05:40 +0200 > Next, I'll turn around completely, and try defaulting to > -fsplit-wide-types-early, which sounds more promising. :) I don't like > throwing defaults around randomly, but trying out a promising idea > this way is easy. Absolutely nothing changed (not counting now running "subreg2" and generating a dump-file), compared to the default. Besides coremark and local micro-benchmarks I inspected running arith-rand-ll.c with -O2 and briefly stepped through the passes with gdb: the costs guiding the splits are fine, properly enabling the splits, but not all DImode registers are naturally "splittable"; looks like the ones used in non-decomposable operations remain. It seems all splittable opportunities are dealt with by the first pass ("subreg1"). I guess this pass has the most impact for targets that have few or no DImode operations at all. But why is the option called -fsplit-wide-types-early when what it does is enabling a "subreg2" pass, there being "subreg1" and "subreg3" enabled with -fsplit-wide-types? It should rather be called -fsplit-wide-types-second! :) Looking at its placement in passes.def makes me wonder what magic properties targets have that benefit from it. Anyway, Roger mentioned that the clobbers emitted by the lower-subreg passes were apparently damaging, so I'll try this out "for fun", on the assumption that they're actually unnecessary. I don't think actually removing them has been attempted? The patch below seems to substantially lower register pressure for arith-rand-ll for CRIS, but I've only inspected the assembly source (not even compared the result to the reload version). Quoting it for reference only, and if it "works" (passes regtest for cris-elf and x86-64-linux) I think I'll resubmit as a proper patch: --- lower-subreg.cc.orig 2023-04-29 02:53:39.000000000 +0200 +++ lower-subreg.cc 2023-05-12 15:35:25.574668930 +0200 @@ -1086,9 +1086,6 @@ resolve_simple_move (rtx set, rtx_insn * { unsigned int i; - if (REG_P (dest) && !HARD_REGISTER_NUM_P (REGNO (dest))) - emit_clobber (dest); - for (i = 0; i < words; ++i) { rtx t = simplify_gen_subreg_concatn (word_mode, dest, brgds, H-P