This is the mail archive of the
mailing list for the GCC project.
Do we create new insn in combine? Or can we rely on INSN_LUID checking the order of instuctions?
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 11 Dec 2014 15:13:50 +0800
- Subject: Do we create new insn in combine? Or can we rely on INSN_LUID checking the order of instuctions?
- Authentication-results: sourceware.org; auth=none
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
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?