Re: Exception causing insns in delay slots

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

>  > I must admit that I find it strange that the compiler puts these
>  > insns into the delay slot at all.  In all other cases, the delay
>  > slot insn executes before the branch is actually taken.  This seems
>  > inconsistent.
> It's not inconsistent.
> 
> The branch executes before its delay slot -- only the side effect of
> changing
> flow control happens after the delay slot.  All other effects such as
> generation of the return address into the return register occur _before_ the
> delay slot instruction.

Yes, the branch actually just updates iaoq_next.  However, when a branch
follows a branch, the second branch modifies the insn queue so that
one insn at the target of the first branch is executed, then the flow
transfers to the target of the second branch.  This differs from what
happens with the return pointer optimization where the effect doesn't
take place until the return of the function called.  You can create
a two insn timer loop using this capability and there is a significant
performance improvement on older machines without branch prediction.

I still think that a branch in the delay slot of another branch (call)
on the PA is not equivalent to the return pointer optimization (assuming
the adjustment can be made).

> call/return stack for predicting branches.  This is why we disable it
> anytime
> we're optimizing for a PA8000 or newer machine.

I looked at output_call again and I couldn't see that this is disabled
for PA8000 or newer machines.  In the dw2 testing, we were definitely
getting unconditional branches in the delay slot of calls on PA8000
or newer machines.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)