<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>during instruction selection of the LLVM memory intrinsics
(llvm.mem{cpy,set,move}) to the corresponding C library functions,
SelectionDAG ignores the actual type of the "len" argument and
asks the target for the preferred type (via DataLayout's
getIntPtrType()).<br>
This introduces implicit truncations of the len argument in case
the i64 variant is used on a 32-bit target.</p>
<p>In contrast, GlobalISel simply forwards the arguments of the
intrinsic call, including their types, to the call to the C
library function. This results in wrong code generation of the i64
versions of these intrinsics on 32-bit architectures.</p>
<p>The IRBuilder hard-codes the type of the len argument to i64 for
some of its functions. In <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D76283">https://reviews.llvm.org/D76283</a> I
propose to change those functions to ask the target for its
preferred type. However, the problem still exists for hand-written
IR.</p>
<p>I see two options: <span class="transaction-comment"
data-sigil="transaction-comment" data-meta="0_15">either 1)
extend GlobalISel to select to the appropriate type, potentially
introducing truncations, or 2) declare this as illegal LLVM IR
in the first place.<br>
During the review, additional concerns were raised regarding
different address spaces having varying bit-widths.</span></p>
<p><span class="transaction-comment"
data-sigil="transaction-comment" data-meta="0_15">Is there a
preferred way to fix this?</span></p>
<p><span class="transaction-comment"
data-sigil="transaction-comment" data-meta="0_15">Thanks,</span></p>
<p><span class="transaction-comment"
data-sigil="transaction-comment" data-meta="0_15">Konstantin<br>
</span></p>
</body>
</html>