Branch instructions that depend on target distance

[Jeff Law]

On Mon, 2020-02-24 at 12:36 +0100, Petr Tesarik wrote:
> On Mon, 24 Feb 2020 11:14:44 +0000
> Jozef Lawrynowicz <jozef.l@mittosystems.com> wrote:
> 
> > On Mon, 24 Feb 2020 12:05:28 +0100
> > Petr Tesarik <ptesarik@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