On Mon, 2 Jan 2006, Ian Lance Taylor wrote:
> When did the bogus split
> happen?
Sorry, I didn't answer this question and now the gdb session is
gone. Hopefully the answer isn't that important given RTH's
comment? I'd guess reorg.
brgds, H-P
On Mon, Jan 02, 2006 at 08:10:21PM -0800, Ian Lance Taylor wrote:
> And flow2 calls split_all_insns before the
> prologue and epilogue insns are threaded. When did the bogus split
> happen?
There are at least 3 post-reload split points.
r~
On Mon, Jan 02, 2006 at 10:35:40PM -0500, Hans-Peter Nilsson wrote:
> I was just bitten by the same behavior for define_split.
> Should the same go for define_splits ...
Um, sure.
> and maybe also as a guard test for combine?
That would be silly, since the note doesn't exist that early.
r~
On Mon, 2 Jan 2006, Ian Lance Taylor wrote:
> 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 threade
Hans-Peter Nilsson <[EMAIL PROTECTED]> 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 sa
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 c
On Mon, Dec 19, 2005 at 02:11:46PM -0800, Ian Lance Taylor wrote:
> I think an algorithm which should work fairly reliably in the general
> case is:
>
> 1) Are there any old insns with RTX_FRAME_RELATED_P set?
> If no, stop.
> 2) For each old insn with RTX_FRAME_RELATED_P set:
> a) i
Andrew Haley <[EMAIL PROTECTED]> writes:
> The problem that is bugging me is if there is more than one
> instruction in the repleacement sequence, which one do you copy the
> REG_FRAME_RELATED_EXPR to?
I think an algorithm which should work fairly reliably in the general
case is:
1) Are there
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > On i386 we replace (add sp -4) with (push reg). This generates faster
> > and smaller code.
> >
> > However, we are not copying RTX_FRAME_RELATED_P from the old
> > instructions to the new, and so we are not emittin
Andrew Haley <[EMAIL PROTECTED]> writes:
> On i386 we replace (add sp -4) with (push reg). This generates faster
> and smaller code.
>
> However, we are not copying RTX_FRAME_RELATED_P from the old
> instructions to the new, and so we are not emitting unwind information
> for the stack pointer a
On i386 we replace (add sp -4) with (push reg). This generates faster
and smaller code.
However, we are not copying RTX_FRAME_RELATED_P from the old
instructions to the new, and so we are not emitting unwind information
for the stack pointer adjustment. The breaks stack traces on gcj, and
I susp
11 matches
Mail list logo
