This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Do we create new insn in combine? Or can we rely on INSN_LUID checking the order of instuctions?

I am looking into distribute_notes, one reason why it's complicated is
the live range of register noted by REG_DEAD could be both shrunk or
extended.  When live range shrinks, we need to search backwards to
find previous reference and mark it as REG_DEAD (or delete the
definition if there is no reference anymore); when live range extends,
we need to search forward to see if we can mark later reference as
REG_DEAD.  Maybe the reason why distribute_notes is so vulnerable is
because it guesses how to distribute DEAD note based on other
information (elim_ix, i2, i3, etc..), rather than how register's live
range changes.
For example, PR62151 shows the case in which the REG_DEAD should be
discarded, but distribute_notes falsely tries to shrink the live range
(even worse, from a wrong point), resulting in wrong instruction

So I am wondering if I can rely on INSN_LUID checking orders of
difference instruction.  If it can be done, I can easily differentiate
live range shrink and extend.
Further question is, if we don't insert new insns, can I use INSN_LUID
safely for this purpose?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]