This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM THUMB: fundamental bug in handling of far jumps?
- From: Adrian von Bidder <avbidder at acter dot ch>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc devel mailing list <gcc at gcc dot gnu dot org>
- Date: 29 Jan 2002 11:24:25 +0100
- Subject: Re: ARM THUMB: fundamental bug in handling of far jumps?
- References: <1012232648.2879.2.camel@atlas> <20020128104253.C25844@redhat.com>
On Mon, 2002-01-28 at 19:42, Richard Henderson wrote:
> On Mon, Jan 28, 2002 at 04:44:08PM +0100, Adrian von Bidder wrote:
> Because it wants to generate
>
> b[cond] .SILLY
> .LABEL
> ...
> .SILLY
> add r2 r3
> b .LABEL
>
> You can turn off some of this with -fno-reorder-blocks.
Hi,
that's clear, as far as it is about jumping around a conditional jump. I
do not understand why the above would be preferred over
b[!cond] .LABEL
add r2, r3
.LABEL:
with the latter having at least one (two, if it's a far
jump-with-jump-around-the-conditional)
> You can turn off some of this with -fno-reorder-blocks.
I see. Is this option documented? It's not in the info doc I have
installed here (says it applies to 3.1, but I'm not sure when I
installed it.)
With all this: any hints to were I would disable the use of lr as a
scratch register? I'd guess it's in arm.h, but it wasn't obvious enough
for me on a first look. (I don't understand enough gcc internals to
change handling of far jumps to record the fact that lr is overwritten.)
greets from Zürich
-- vbi