This is the mail archive of the
mailing list for the GCC project.
ARM THUMB: fundamental bug in handling of far jumps?
- From: Adrian von Bidder <avbidder at acter dot ch>
- To: gcc devel mailing list <gcc at gcc dot gnu dot org>
- Date: 28 Jan 2002 16:44:08 +0100
- Subject: ARM THUMB: fundamental bug in handling of far jumps?
I'm not entirely sure yet, but perhaps somebody else is and has seen
On ARM Thumb, with gcc-3.0.3 at least, it seems gcc can use lr as a
general register. This fine by me, but apparently it 'forgets' that the
bl instruction - which it uses for far jumps - overwrites lr.
As lr is apparently only chosen if no other register is free, I've only
been able to trigger this in a very big function (due to inlining with a
-minline-limit=HUGE_VALUE). But as this inlining option gives a huge
speed gain in our program, I'd really like to use it.
I'll have a look in the source code tomorrow, perhaps it's something
obvious. But - as always - I'd be glad of your help.
btw: the far jumps I'm seeing are often in code like this
... (a few hundred instructions)
.SILLY: add r2, r3 (just some random conditional op)
Most of the time, it's really only one instruction and then jump back.
Sometimes it's five, six, or even a few dozens. While I have no data
about how often these jumps are taken, it's plain that in the case they
are taken, the two extra jumps are time needlessly wasted (besides
invalidating lr). Why does gcc emit code like this? (I could imagine
that it is to enhance the effectivity of caches - but arm7tdmi has none,
so it would be great to at least make the generation of these
greets from Zürich