On Mon, 2020-02-24 at 12:36 +0100, Petr Tesarik wrote: > On Mon, 24 Feb 2020 11:14:44 +0000 > Jozef Lawrynowicz <joze...@mittosystems.com> wrote: > > > On Mon, 24 Feb 2020 12:05:28 +0100 > > Petr Tesarik <ptesa...@suse.cz> wrote: > > > > > Hi all, > > > > > > I'm looking into reviving the efforts to port gcc to VideoCore IV [1]. > > > One issue I've run into is the need to find out target branch distance > > > at compile time. I looked around, and it's not the first one > > > architecture with such requirement, but AFAICS it has never been solved > > > properly. > > > > > > For example, AVR tracks instruction length. Later, ret_cond_branch() > > > selects between a branch instruction and an inverted branch followed by > > > an unconditional jump based on these calculated lengths. > > > > > > This works great ... until there's some inline asm() statement, for > > > which gcc cannot keep track of the length attribute, so it is probably > > > taken as zero. Linker then fails with a cryptic message: > > > > > > > relocation truncated to fit: R_AVR_7_PCREL against `no symbol' > > > > The MSP430 backend just always generates maximum range branch instructions, > > except for some special cases. We then rely on the linker to relax branch > > instructions to shorter range "jump" instructions when the destination is > > within range. > > > > So the compiler output will always work, but not be the smallest possible > > code > > size. > > > > For that relocation truncated to fit error message you want to check that > > the > > linker has the ability to relax whatever branch instruction it is failing > > on to > > a longer range branch. > > But that would change the instruction length, so not really an option > AFAICS (unless I also switch to LTO). > > Anyway, the situation is much worse on the VideoCore IV. The > alternatives here are: > > 1. > addcmpbCC rx, 0, imm, target > ; usually written as bCC rx, imm, target > > 2. > cmp rx, imm > bCC .+2 > j target Yea, this isn't that uncommon. You can describe both of these to the branch shortening pass.
> > The tricky part is that the addcmpbCC instruction does NOT modify > condition codes, while the cmp instruction does. Nothing you could > solve in the linker... > > OK, it seems I'll have to go with the worst-case variant. You can support both. You output the short case when the target is close enough and the longer variant otherwise. Jeff
