This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

ARM THUMB: fundamental bug in handling of far jumps?


I'm not entirely sure yet, but perhaps somebody else is and has seen
this behaviour...

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

	cmp [something]
	b[cond] .LABEL
	bl	.SILLY
.LABEL:	...
	...		(a few hundred instructions)
.SILLY:	add r2, r3 	(just some random conditional op)
	bl	.LABEL

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
trampolines conditional).

greets from Zürich
-- vbi

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]