This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: peephole vs RTX_FRAME_RELATED_P
- From: Ian Lance Taylor <ian at airs dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Andrew Haley <aph at redhat dot com>, gcc at gcc dot gnu dot org, java at gcc dot gnu dot org
- Date: 02 Jan 2006 20:10:21 -0800
- Subject: Re: RFC: peephole vs RTX_FRAME_RELATED_P
- References: <17318.64145.41810.488474@zapata.pink> <m38xuglvrk.fsf@gossamer.airs.com> <17319.3754.844531.876599@zapata.pink> <m34q54lot9.fsf@gossamer.airs.com> <20051220073124.GA3576@redhat.com> <Pine.BSF.4.58.0601022227260.18683@dair.pair.com>
Hans-Peter Nilsson <hp@bitrange.com> writes:
> On Mon, 19 Dec 2005, Richard Henderson wrote:
> > I think that this is all complicated enough that we should
> > simply deny peepholing insns with RTX_FRAME_RELATED_P set.
>
> I was just bitten by the same behavior for define_split.
> Should the same go for define_splits and maybe also as a guard
> test for combine? Maybe a utility function to use by all insn
> transformations?
I wouldn't expect to see any insns with RTX_FRAME_RELATED_P set before
the prologue and epilogue are threaded in the flow2 pass. So combine
shouldn't be an issue. And flow2 calls split_all_insns before the
prologue and epilogue insns are threaded. When did the bogus split
happen?
Ian