This is the mail archive of the
mailing list for the GCC project.
Re: Frame-related delay slot insns
Daniel Jacobowitz <firstname.lastname@example.org> writes:
> On Tue, May 06, 2003 at 03:00:10PM -0700, Richard Henderson wrote:
> > On Tue, May 06, 2003 at 07:55:50PM +0100, Richard Sandiford wrote:
> > > > > LB:
> > > > > LD1:
> > > > > ...
> > > > > LDn:
> > > > > B
> > > > > D1
> > > > > ...
> > > > > Dn
> > [...]
> > > Even when there are dependencies between the insns? I assumed the
> > > effects would still be sequential, i.e. we'd do the equivalent of:
> > >
> > > advance to LB
> > > do EB
> > > advacne to LD1
> > > do ED1
> > Except that the distance between those labels is 0,
> > so there's no advance, so we apply all of the
> > effects at LDn:.
Understood, but I'm thinking about the cases where there are dependencies
between some of EB, ED1 ... EDn. Say one adjusts the stack and another
has an sp-relative store. In that case, I thought the order of the
dwarf operations would matter, even though there's no advance
> I guess what Richard S. is trying to get at is whether the branch's
> effects are applied first or last.
Right. To take a more specific example, suppose there's a call insn
that adjusts the stack. Does the SEQUENCE construct allow it's
delay slot to be filled with an insn that stores something relative
to the stack? As far as I know, reorg isn't able to create such a
sequence. But does that mean they aren't valid? If they are valid,
does the adjustment happen before or after the store?
In other words, is there a definition of SEQUENCE that makes one
order more correct than the other? Does SEQUENCE have its own
"semantics", or is it really just anything that reorg can generate
(no more, no less).
Anyway, it looks like I've managed to confuse the issue. ;)
If the relative order of the frame ops really doesn't matter,
it sounds like both of the patches I posted should do what I want.
I guess the second one is a bit cleaner.
Is the patch more-or-less OK?