From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36734 invoked by alias); 24 Feb 2020 11:36:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 36725 invoked by uid 89); 24 Feb 2020 11:36:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS,URIBL_RHS_DOB autolearn=no version=3.3.1 spammy=tricky X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Feb 2020 11:36:47 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F33A6ACB8; Mon, 24 Feb 2020 11:36:44 +0000 (UTC) Date: Mon, 24 Feb 2020 11:36:00 -0000 From: Petr Tesarik To: Jozef Lawrynowicz Cc: gcc@gcc.gnu.org Subject: Re: Branch instructions that depend on target distance Message-ID: <20200224123641.27c8b5eb@ezekiel.suse.cz> In-Reply-To: <20200224111444.6ca8e0d8@jozef-kubuntu> References: <20200224120528.0a88c6a8@ezekiel.suse.cz> <20200224111444.6ca8e0d8@jozef-kubuntu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/lu5ApZ2grfZ9cmPb.SJBMz7"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00182.txt.bz2 --Sig_/lu5ApZ2grfZ9cmPb.SJBMz7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-length: 3276 On Mon, 24 Feb 2020 11:14:44 +0000 Jozef Lawrynowicz wrote: > On Mon, 24 Feb 2020 12:05:28 +0100 > Petr Tesarik wrote: >=20 > > Hi all, > >=20 > > 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. > >=20 > > 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. > >=20 > > 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: > >=20=20=20 > > > relocation truncated to fit: R_AVR_7_PCREL against `no symbol'=20=20= =20=20 >=20 > The MSP430 backend just always generates maximum range branch instruction= s, > 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. >=20 > So the compiler output will always work, but not be the smallest possible= code > size. >=20 > 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 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. Petr T >=20 > Jozef > >=20 > > I can provide a minimal test case and report a bug if you want... > >=20 > > Developers work around the issue by rewriting their code when they > > are bitten by this, but it is less than optimal, because you cannot > > really get rid of all inline assembly, and it's in general > > unpredictable where these inline asm() blocks will be placed by the > > compiler. > >=20 > > OTOH, the avr backend is pretty outdated, so there may be a better > > alternative that I'm just not seeing. Any hints? > >=20 > > Background: There is a port of the VC4 port of the LK embedded > > kernel [2]. I have tried to build that kernel with optimization > > turned on, but I'm getting: > >=20 > > compiling kernel/thread.c > > /tmp/ccJFdnfX.s: Assembler messages: > > /tmp/ccJFdnfX.s:1451: Error: operand out of range (64 not between > > -64 and 63) > >=20 > > That's because there is an inline "di" (disable interrupts) > > instruction inside a conditional statement in thread_yield(), which > > causes this off-by-one miscalculation. > >=20 > > Petr T > >=20 > > [1] https://github.com/itszor/gcc-vc4 > > [2] https://github.com/librerpi/lk=20=20 >=20 --Sig_/lu5ApZ2grfZ9cmPb.SJBMz7 Content-Type: application/pgp-signature Content-Description: Digitální podpis OpenPGP Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEHl2YIZkIo5VO2MxYqlA7ya4PR6cFAl5TtUkACgkQqlA7ya4P R6ctsQgAm75nCy2uqWP1FlUkFOe0uWmWKOVoJcMlS3lb4BvXLc7j+VK7DEZVrl1y J3RbwurK2UxepJ2/d4047mXnmWykMpKeNuxASo7oiNdNjj8+YHPghcz0PbrY55qV pM9PjmpDmyQZCVx3YgSSuTDW9Q1a2nhlUomaJDriipMplFiSwjMpf1oYnrZOsPs/ OoPy6F6yisBXGIlNs41AToFCacbCyfw9DZD4i50t03Fi6nCXd2q0S7Xo/f2x3O7A /9I9JSCzTaAIeZ1qOPH+44ylvZwNKcE3qRidpc6UE3V+iEr5VlmFNXbxgGMpayq2 j8V3Q826n++ckX8GUKZTVAb5WV/MFg== =ylwi -----END PGP SIGNATURE----- --Sig_/lu5ApZ2grfZ9cmPb.SJBMz7--