This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Branch instructions that depend on target distance
- From: Jeff Law <law at redhat dot com>
- To: Petr Tesarik <ptesarik at suse dot cz>, Jozef Lawrynowicz <jozef dot l at mittosystems dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 24 Feb 2020 08:12:32 -0700
- Subject: Re: Branch instructions that depend on target distance
- References: <20200224120528.0a88c6a8@ezekiel.suse.cz> <20200224111444.6ca8e0d8@jozef-kubuntu> <20200224123641.27c8b5eb@ezekiel.suse.cz>
- Reply-to: law at redhat dot com
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