This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Frame-related delay slot insns


Thanks for the detailed explanation!

law@redhat.com writes:
> On the PA insns with a delay slot can have multiple side effects.  For
> example, they may increment a register, change the PC, transfer a 
> link address into a register, etc.
> 
> For the insn with the delay slot, the semantics are that the only
> delayed effect is the transfer of control.  ie, all other side effects
> such as incrementing a register, clearing a register, setting up a
> link register, etc happen immediately.
> 
> The side effects of the insn in the delay slot will occur after the
> non-control side effects of the insn with the delay slot.  Then finally
> the control transfer of the insn with the delay slot will occur.

Ah, right.  Let me see if I've got this straight.  The kind of the
code I'm thinking about is:

        ...some stuff...
        B               (delayed call with frame-related expr EB)
        D1              (delay slot 1 with frame-related expr ED1)
        ...
        Dn              (delay slot n with frame-related expr EDn)

Before the patch, we generated:

        ...some stuff...
LB:
        B
        D1
LD1:
        ...
        Dn
LDn:

In the unwind info, EB will take effect at LB, ED1 at LD1, etc.
As I understand it, the whole sequence (B...Dn) is supposed to
take effect before the call insn (i.e. where LB is now).

With my patch we generated:

        ...some stuff...
LD1:
...
LDn:
LB:
        B
        D1
        ...
        Dn

but it sounds from what you say like the PA needs:

        ...some stuff...
LB:
LD1:
...
LDn:
        B
        D1
        ...
        Dn

instead.

As far as I can tell, we never pass JUMP_INSNs to dwarf2out_frame_debug.
The difference between the two sequences should only matter for delayed
calls, not for delayed branches.  Is that right?

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]