From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9C88A385DC2F; Thu, 1 Feb 2024 20:24:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C88A385DC2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706819084; bh=luxs48k9tfIzoUmpyGyxOWWqL734wwbCf+lwR3ew0dc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OhGxASfEIDCfbuFERAknQ7MKcM+26nPkb4sqbkDB3kjNOxNlcFlzfE93thi5lCI+8 zY6sQD8YPB7neGxrz4Bj2GYRLO+ugQqaSTxg8xCCyW2gnFf5TEnto0VzepVF6zzf5B ooZz81njEOtelKgw1SyIaThZ6DzMSwmQi3qQjpRU= From: "hpa at zytor dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/113686] [RISC-V] TLS (Local Exec) relaxation on structures (LE) Date: Thu, 01 Feb 2024 20:24:43 +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: 13.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hpa at zytor dot com X-Bugzilla-Status: NEW 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: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113686 --- Comment #2 from H. Peter Anvin --- The intermediate alignment for lui is known, so if an object is known to fit *entirely* within its natural alignment then it can be safely CSE'd, but th= is is typically not the case with structures or arrays. It would be nice to fix this in the architecture (as a new standard extensi= on). Unfortunately, due to the decision to allocate 3/4 of the instruction encod= ing space to 16-bit instructions only 3 completely reserved 5-bit opcodes remai= n - and that is only what is currently in the ISA document. Adding "auipc1" and "lui1" would consume two of those (they would most naturally fall at op =3D 1X10011) There are some less desirable options, like reclaiming part of the encoding space for longer instructions (requiring another 1 bit in the prefix for lo= ng instructions would provide the additional two encodings); on RV32 *only* the RV64 encoding space op =3D 0X11011 could be used, but I doubt it would be m= uch appreciated to have this capability on RV32 and not RV64. (Not to mention hacks like only having part of the register space accessibl= e, which wouldn't necessarily be horrendous, though, as these instructions wou= ld belong in some pretty fixed patterns.) One could also say that auipc1 would be "good enough" (combined with PC-relative relocations for TLS, at least for the TE model) and would still= be valuable enough to occupy a full opcode. (Obviously, the idea would be that these instructions really are pseudo-instructions carrying one more immediate bit, and that the linker wo= uld apply those bits using "HI21" relocations.) I think this is something where the ISA architects could really use to hear from you compiler developers; since I'm not really familiar with where the = pain points in the compiler lie, it is hard for me to speak authoritatively.=