Memory intrinsics len argument type


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()).
This introduces implicit truncations of the len argument in case the i64 variant is used on a 32-bit target.

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.

The IRBuilder hard-codes the type of the len argument to i64 for some of its functions. In I propose to change those functions to ask the target for its preferred type. However, the problem still exists for hand-written IR.

I see two options: 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.
During the review, additional concerns were raised regarding different address spaces having varying bit-widths.

Is there a preferred way to fix this?