This is the mail archive of the
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>
> In message <email@example.com>, Richard Sandiford w
> >Richard Sandiford <firstname.lastname@example.org> 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?