https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- I worked on avr issues quite some time. And here is my findings. Before IRA we have start of BB2: ;; lr in 14 [r14] 15 [r15] 16 [r16] 17 [r17] 18 [r18] 19 [r19] 20 [r20] 21 [r21] 22 [r22] 23 [r23] 24 [r24] 25 [r25] 28 [r28] 32 [__SP_L__] 34 [argL] 44 45 46 33: r51:QI=r22:QI REG_DEAD r22:QI 34: r52:QI=r23:QI REG_DEAD r23:QI 35: r53:QI=r24:QI REG_DEAD r24:QI 36: r54:QI=r25:QI REG_DEAD r25:QI 37: r44:SI#0=r51:QI REG_DEAD r51:QI 38: r44:SI#1=r52:QI REG_DEAD r52:QI 39: r44:SI#2=r53:QI REG_DEAD r53:QI 40: r44:SI#3=r54:QI REG_DEAD r54:QI According GCC pseudo r44 conflicts with r51, r52 ... In reality it is not. I could modify BB live analysis in IRA although it is a lot of work. But there is a bigger problem. A lot of passes including IRA uses data-flow analysis framework for global life analysis and it does not work on subreg level. You can see that r44 still lives (lr in) at the beginning of BB2. DFA is not my responsibility but I can say modifying DFA this way is a huge project as it will affect a lot of targets. Instead, as AVR regs are very small, I propose to avoid the above RTL code by switching off subreg3 pass (or -fsplit-wide-types) for AVR by default as it was for gcc-8. There is still one minor problem: an additional reg-reg move generation for the test case in comparison with gcc-8. I'll try to fix it.