This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: patch candidate for PR target/16665 (Was: Re: Quo vadis, thunk?)
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: mark at codesourcery dot com (Mark Mitchell)
- Cc: joern dot rennecke at superh dot com (Joern Rennecke), gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, kkojima at rr dot iij4u dot or dot jp (Kaz Kojima)
- Date: Tue, 3 Aug 2004 19:11:07 +0100 (BST)
- Subject: Re: patch candidate for PR target/16665 (Was: Re: Quo vadis, thunk?)
> *Technically* the number of thunks to a function is unbounded, so you
> could still get so many of them that you had an out-of-range branch. In
> practice, I wouldn't expect that to happen.
I am aware of this. Call it an implementation limit. The bra
instruction gives you a +- 4KByte range. With 32 byte function alignment,
that gives you 128 thunks. But if you have thunk-rich code, you will
be better off lowering this alignment anyway, and if you set it to
4 bytes, the most basic non-virtual thunk will indeed fit into 4 bytes.
Virtual thunks are typically something like 12 bytes.
If you exceed the address range, your inheritance hierarchy is likly
to be seriously messed up.
If someone is really worried about this, we can do fancy stuff with
assembler pseudo-ops or linker relaxation...
Actually, for a solution using an assembler pseudo-op, the most fancy bit
would likely be the testcase.
For the SH5, this is an abosulte non-issue. The offset range of pta
is +-128Kbyte, and the assembler can expand a pt into a
movi / shori / ptrel sequence if pta doesn't reach.
This is also the reason why I could use UNSPEC_PIC for the SH5, but had
to use a different unspec for SH1..4.
Of course you could still run out of virtual address space, which is
4 Gbyte for the SHmedia32 ABI, and 16 Exabytes for the SHmedia64 ABI.