This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: reorg branch displacement fix
- From: Jeff Law <law at porcupine dot cygnus dot com>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: tm <tm at mail dot kloo dot net>, kkojima at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 01 Nov 2002 16:47:59 -0700
- Subject: Re: PATCH: reorg branch displacement fix
- Reply-to: law at redhat dot com
In message <3DC30C82.89D0FFEC@superh.com>, Joern Rennecke writes:
>It used to be possible to hide these spurious redirection 'opportunities',
>but reorg has become more aggressive in this aspect.
Which means that your backend is abusing the facilities in the generic
parts of the compiler.
> We are not talking
>about a problem of making an optimization in reorg, but about avoiding invali
>d transformations there.
Reorg has always been designed to not worry about the potential of
lengthening branches. Those are for shorten-branches and the backend
to deal with. reorg has always worked under the assumption that it can
thread a branch and not worry about if that lengthens the branch. In
fact that's part of its fundamental design.
>There is no such thing as a conditional branch with an infinite offset on the
> SH,
Similarly for the PA, sparc and various other ports.
>Are you suggesting I should disable the putatively machine-independent delay
>slot
>scheduling for the SH and instead roll my own in the SH backend?
I'm suggesting you fix your backend to work within the framework and
assumptions made by the generic parts of the compiler.
jeff