https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108018
Avinash Jayakar <avinashd at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |avinashd at gcc dot gnu.org
--- Comment #2 from Avinash Jayakar <avinashd at gcc dot gnu.org> ---
before sched2 pass, below is the rtl:
18: %3:DI=high(unspec[`*.LANCHOR0',%2:DI] 47)
19: %3:DI=%3:DI+low(unspec[`*.LANCHOR0',%2:DI] 47)
20: %9:DI=high(unspec[`*.LANCHOR0',%2:DI] 47+0x4)
21: %9:DI=%9:DI+low(unspec[`*.LANCHOR0',%2:DI] 47+0x4)
REG_DEAD %2:DI
REG_EQUAL const(`*.LANCHOR0'+0x4)
13: %3:DI=%3:DI+%9:DI
and this is after the scheduling runs post reg alloc (sched2):
18: %3:DI=high(unspec[`*.LANCHOR0',%2:DI] 47)
20: %9:DI=high(unspec[`*.LANCHOR0',%2:DI] 47+0x4)
19: %3:DI=%3:DI+low(unspec[`*.LANCHOR0',%2:DI] 47)
21: %9:DI=%9:DI+low(unspec[`*.LANCHOR0',%2:DI] 47+0x4)
REG_DEAD %2:DI
REG_EQUAL const(`*.LANCHOR0'+0x4)
13: %3:DI=%3:DI+%9:DI
19 and 20 are reordered to favour dependency delays.
The scheduler only looks if target has implemented
TARGET_SCHED_MACRO_FUSION_PAIR_P, and does not reorder if it has for specific
sequence.
Just adding define_insn for the sequence actually did not help. Should we
implement TARGET_SCHED_MACRO_FUSION_PAIR_P for rs6000?
