This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Frame-related delay slot insns
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: law at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 06 May 2003 15:49:35 +0100
- Subject: Re: Frame-related delay slot insns
- References: <200305061426.h46EQwwE004760@speedy.slc.redhat.com>
law@redhat.com writes:
> In message <wvnof2g2rjq.fsf@talisman.cambridge.redhat.com>, Richard Sandiford w
> rites:
> >Richard Sandiford <rsandifo@redhat.com> writes:
> >> The (somewhat ugly) patch below was tested on mips-elf, mips64-elf,
> >> mips-sgi-irix6.5, mips64vrel-elf & mipsel-linux-gnu. OK to install?
> >
> >BTW... I was in two minds as to whether the frame effects of the delayed
> >insn should be described before or after the effects of the delay slots.
> >It doesn't matter either way for mips. Are there any back-ends for
> >which it would?
> It would certainly matter on the PA. In fact, one of the nastyiest long
> standing debugging/backtracing issues occurs when you have a function
> where the initial stack pointer adjustment gets pushed down into the
> delay slot of a branch.
OK, thanks. Which way round should it be for PA? Do the effects
described by a call's frame-related expression happen immediately
(before the delay slot insns are executed)? Or are they delayed?
Richard