https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64907
Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #2 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #1)
> Still happens with 5.0.
It is an interesting case but I don't think it will be fixed for GCC-5.0. It
is hard for me to decide how to fix it. But even if I knew how do it it would
need a lot of changes in RA.
Before LRA we have:
2: r91:SI=di:SI
REG_DEAD di:SI
3: NOTE_INSN_FUNCTION_BEG
6: r92:SI=zero_extend(r91:SI#0)
7: di:SI=r92:SI
REG_DEAD r92:SI
8: call [`put_16bit'] argc:0
REG_DEAD di:SI
REG_CALL_DECL `put_16bit'
9: {r93:SI=r91:SI 0>>0x10;clobber flags:CC;}
REG_DEAD r91:SI
REG_UNUSED flags:CC
10: di:SI=r93:SI
REG_DEAD r93:SI
11: call [`put_16bit'] argc:0
P91 gets bx which is saved on in prologue/epilogue according to ABI. P91 can
not get di because of the conflict with its usage in insn range [7..8].
If we spill p91, we get the same code as before
2: bx:SI=di:SI
19: NOTE_INSN_DELETED
3: NOTE_INSN_FUNCTION_BEG
6: di:SI=zero_extend(bx:HI)
8: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
16: di:SI=bx:SI
9: {di:SI=di:SI 0>>0x10;clobber flags:CC;}
11: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
12: barrier
That is because of inheritance in LRA. If we spill p91 and prohibit the
inheritance, we get even worse code
2: [sp:DI+0xc]=di:SI
3: NOTE_INSN_FUNCTION_BEG
6: di:SI=zero_extend([sp:DI+0xc])
8: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
16: di:SI=[sp:DI+0xc]
9: {di:SI=di:SI 0>>0x10;clobber flags:CC
11: call [`put_16bit'] argc:0
REG_CALL_DECL `put_16bit'
12: barrier
I don't think that the PR is important. If we already used ebx somewhere (it
means code with higher register pressure), the code would be ideal because ebx
is already saved for other purposes. So it is mostly a problem for such small
functions only.
Currently I see two solutions: implementation of splitting in IRA which will
be complicated or propagating di from insn 2 to insn 6 in the later code by
some later pass. It would be even more complicated as we need somehow to
decide that IRA should spill p91 and don't do inheritance for it in LRA.
Still I'll think about how to fix it in LRA. But again most probably the PR
will be not fixed for GCC-5.0.
