Re: PATCH: reorg branch displacement fix

[tm <tm at mail dot kloo dot net>]

On Fri, 1 Nov 2002, Jeff Law wrote:

> In message <3DC2FC6F.D75062A5@superh.com>, Joern Rennecke writes:
>  >> > * reorg.c (relax_delay_slots): Don't thread conditional jump
>  >> > through unconditional jump if the conditional jump can't reach
>  >> > the branch target on this processor target.
>  >> This is wrong.  reorg does not and should not be checking branch displaceme
>  >nts.
>  >> That is a problem for shorten-branches and the backend.
>  >
>  >The SH does some early branch shortening in machine_dependent_reorg because
>  >a long conditional branch has to be split into a short conditional branch
>  >around an unconditional branch, or a short conditional branch to an unconditi
>  >onal
>  >branch (that might have been inserted elsewhere after an inverted condbranch)
>  >.
>  >Unconditional branches have mandatory delay slots, so we get additional
>  >delay slots exposed by doing this splitting before reorg, and the conditional
>  >branches have optional delay slots, which obviously can't be used in the same
>  >way when the branch is reversed or redirected.
>  >Thus, machine_dependent_reorg already makes sure all the conditional branches
>  >that need splitting are split.  If reorg redirects conditional branches
>  >willy-nilly, it destroys the very data it is supposed to operate on.
> Regardless, reorg has never been designed to deal with this issue.  It can
> lengthen the distance between branches in various ways other than simple
> redirection.
> 
> This is _NOT_ reorg's problem to solve.  This is the backend's problem to
> solve.

Can we poison MD_CAN_REDIRECT_BRANCH in reorg.c once we remove the other
reference to it?

Toshi