<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2024-05-05 15:02, Cordell Bloor
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9e4440bd-0a79-431c-867b-472796e021c2@slerp.xyz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>There is nothing that can be done in rocm-hipamd to address
this bug, aside from removing arm64 from the rocm-hipamd
architecture list. The incompatibility is not with the HIP
runtime, but with the HIP language<span style="white-space: pre-wrap">. </span><span style="white-space: pre-wrap">This is a disagreement that glibc and llvm will need to resolve between themselves</span><span style="white-space: pre-wrap">.</span></p>
</blockquote>
<p>I reached out to the HIP language compiler team and Sam Liu
indicated that this is an LLVM responsibility. Quoting Sam,</p>
<blockquote type="cite"
cite="mid:9e4440bd-0a79-431c-867b-472796e021c2@slerp.xyz">
<p>Since HIP is single source program, device compilation is
supposed to be able to compile both host and device functions
(parse, not necessarily codegen). As such, clang should know
builtin types for both device and host target in either device
or host compilation. Therefore a proper solution is to let clang
define host-specific builtin types for device target so that
they can be parsed, but restriction may be added for emitting
them in IR.<br>
<br>
For this specific case, HasAArch64SVETypes may be moved from
TargetInfo to TransferrableTargetInfo, so that it is copied from
aux target info to target info in device compilation, then those
builtin types will be enabled for device target<span style="white-space: pre-wrap">.</span></p>
</blockquote>
<p>Sincerely,<br>
Cory Bloor<br>
</p>
</body>
</html>