https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118358
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tnfchris at gcc dot gnu.org
--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks for the report!
I'm not sure it's a loop but just takes a long time.
Is the target backend gcc/config/xtensa/xtensa.md? there are patterns LRA is
using that I can't find.
It looks like almost every arithmetic pattern is causing LRA to insert a reload
like:
Choosing alt 7 in insn 33: (0) r (1) 0 (2) i {addhi3}
Creating newreg=215 from oldreg=25, assigning class GENERAL_REGS to r215
33: {r215:HI=r215:HI+0x20;clobber carry:BI;}
REG_UNUSED carry:BI
Inserting insn reload before:
397: r215:HI=r45:HI
Inserting insn reload after:
398: r25:HI=r215:HI
and
Choosing alt 0 in insn 139: (0) =r (1) 0 (2) ri {ashlhi3}
Creating newreg=236 from oldreg=124, assigning class GENERAL_REGS to r236
139: {r236:HI=r236:HI<<0x1;clobber carry:BI;}
REG_UNUSED carry:BI
Inserting insn reload before:
438: r236:HI=r137:HI
Inserting insn reload after:
439: r124:HI=r236:HI
for instance this BB gets 9000 reloads, which slows liveness analysis down to a
crawl.
I'm not sure why the patterns are causing a reload for every `r` usage, I can't
seem to find the `hi` version of the patterns, only the si ones.
insn 33 is
(insn 33 32 5 7 (parallel [
(set (reg:HI 25 [ ivtmp.62D.2061 ])
(plus:HI (reg/f:HI 45 [ _34 ])
(const_int 32 [0x20])))
(clobber (reg:BI 16 carry))
]) 12 {addhi3}
So it's unclear to me why this requires a reload on the register operand and to
the same class.
That said I tested the commit before my changes at
g:a856b4d97b8d328fdcb169b792ac5456e40f8c00 and can reproduce the same extremely
slow compilation.
I see it generating 12000 reloads and LRA compressing the range down a massive
80%.
It seems like a target bug as it's spilling every single arithmetic
instruction, and doesn't seem like it started with the IVopts changes.
