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.
