[llvm-bugs] [Bug 36862] New: Aarch64: support rN register names
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Mar 21 16:55:21 PDT 2018
https://bugs.llvm.org/show_bug.cgi?id=36862
Bug ID: 36862
Summary: Aarch64: support rN register names
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: manojgupta at google.com
CC: llozano at chromium.org, llvm-bugs at lists.llvm.org,
ndesaulniers at google.com, srhines at google.com
Verbatim copied from
https://bugs.chromium.org/p/chromium/issues/detail?id=824526
The upstream kernel commit f2d3b2e8759a ("arm/arm64: smccc: Implement SMCCC
v1.1 inline primitive")
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f2d3b2e8759a5833df6f022e42df2d581e6d843c)
uses the names "r0", "r1", ... for the general purpose registers that are
usually known as "x0", "x1", ...
Use of the rN register names for arm64 is supported by gcc, but not by clang,
in consequence upstream kernels and v4.14 (LTS/CrOS) currently don't build with
clang for arm64.
Kernel maintainers don't seem to be inclined to use the xN names, probably also
because the code in question is shared between arm64 and arm32, and arm32
registers are named rN.
"I'd say this is really a bug in Clang. Architecturally, the register in
AArch64 state is still named "r0"; "x0"/"w0" are assembler operands which
additionally encode the size of the corresponding *access* to r0."
https://lkml.org/lkml/2018/3/1/186
Maintainers might accept a fix, but expect LLVM to work on supporting rN
register names for arm64 in future releases:
"It would be preferable to see evidence of the llvm community committing to fix
this before we consider merging a bodge into Linux for it."
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180321/d120fc0d/attachment.html>
More information about the llvm-bugs
mailing list