This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Repost: RFA [4.1]: improvement to if-conversion and cross-jumping (PR20070)
- From: Joern RENNECKE <joern dot rennecke at st dot com>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: Steven Bosscher <stevenb at suse dot de>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, jh at suse dot cz
- Date: Wed, 30 Nov 2005 23:53:44 +0000
- Subject: Re: Repost: RFA [4.1]: improvement to if-conversion and cross-jumping (PR20070)
- References: <41E59432.7080504@st.com> <42CD71E0.3070804@st.com> <42D3B666.6050701@st.com> <200507121547.21305.stevenb@suse.de> <42D3E705.9030507@st.com> <42D7C264.6030507@st.com> <438C567A.7030104@t-online.de> <438CCE0F.6020209@st.com> <438DC224.8020300@t-online.de> <438E1734.3090502@st.com> <438E3361.6050403@t-online.de>
Bernd Schmidt wrote:
Nevermind the fact that this has a duplicate call of validate_change.
What is this code trying to do? I would have naively thought that if
we have R5 and R0 live at the end, then previous uses of either
register must match exactly.
Can you post an RTL example of what you're trying to accomplish with
the code related to input_reg? What can be done with it that can't be
done by examining the local_regs still live at the start of a block?
input_reg is for a register that is *not* local to the block, but
remains unaltered. In principle, we could also match constants here,
but I haven't had sufficient motivation (as in: appears to be relevant
to performance according to the benchmarks I've looked at) so far. We
should only encounter it as an rvalue.
When we are processing REG_NOTES, e..g REG_EQUAL, it is quite possible
that we see a note later in the insn stream than the actual last use in
insn patterns, i.e. scanning backwards
we'll see these notes first. In order to recognize them, we have to use
information from a previous pass.
input_reg is expected to be only set once for each block matching, but
it is thinkable that strange backtracking with equivalences will cause
us to discard an input reg and use a different one.
This might not actually be possible in the current code, but it seems
too fragile to rely on that.