From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id BB9E4388B03B; Wed, 27 May 2020 09:17:47 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BB9E4388B03B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1590571067;
 bh=kn1NVN/CTtfRYRM1L+A/JoKKnhHtAMLhfVgRfReXGqk=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=KYC4tuHkyDL/U8wZi+He9zS1cadgej7EPrPppUXXz1p6gpNmXE4qiFgH2nOTqou7e
 Bx+UtdtD7d7SbQgyJCMoo/r1G58WGuLlSCGaaV74bfoZ/AF2gCGOsWuNMaHZl3JXY9
 ETkv8pSnR6eN/pmImRCHFKnWp4ksg93nRlFfMW78=
From: "bule1 at huawei dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/95285] AArch64:aarch64 medium code model proposal
Date: Wed, 27 May 2020 09:17:47 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bule1 at huawei dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-95285-4-p1jes6Hmxc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-95285-4@http.gcc.gnu.org/bugzilla/>
References: <bug-95285-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2020 09:17:47 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95285

--- Comment #7 from Bu Le <bule1 at huawei dot com> ---
(In reply to Wilco from comment #5)
> (In reply to Bu Le from comment #0)
>=20
> Also it would be much more efficient to have a relocation like this if you
> wanted a 48-bit PC-relative offset:
>=20
> adrp    x0, bar1.2782
> add     x0, x0, :lo12:bar1.2782
> movk 	  x0, :high32_47:bar1.2782

I am afraid that put the PC-relative offset into x0 is not correct, because=
 x0
issuppose to be the final address of bar1 rather than an PC offset. Therefo=
re
an extra register is needed to hold the offest temporarily. Later, we need =
to
add the PC address of the movk with the offset to calsulate 32:48 bits of t=
he
final address of bar1. Finally, add this part of address with x0 to compute=
 the
entire 48 bits final address. So the code sould be following sequence:

adrp    x0, bar1.2782
add     x0, x0, :lo12:bar1.2782  //x0 here hold the 0:31 bits of the final =
addr
movk    x4, :prel_g2:bar1.2782
adr     x1, .
sub     x1, x1, 0x4
add     x4, x4, x1   // x4 here hold the 32:47 bits of the final addr
add     x0, x4, x0

(By the way, the high32_47 relocation you suggested is the prel_g2 in the
officail aarch64 ABI released)

So acctually, if we just want a 48-bit PC-relevent relocation, your idea and
mine both need 6-7 instructions to get the symbol. In terms of efficiency, =
it
would be similar.=20

And in terms of engineering, you idea can save the trouble to modify the li=
nker
for calculating the offset for 3 movks. But we still need to make a new
relocation type for ADRP, because it currently checking the overflow of add=
ress
and gives the "relocation truncated to fit" error. Therefore, both idea nee=
d to
do works in binutils, which make it also equivalent.=