Open coding builtin_memset should not be faster

[JonChesterfield]

PR #143607 for libc replaces a builtin_memset with an open coded equivalent and reports substantial performance gains (and minor reg count increase). That shouldn't be possible.

memset (and memcpy, memmove etc) have completely specified semantics and intrinsics with alignment metadata and similar on them. The backend could be lowering those optimally. In particular, enabling inactive lanes in the exec mask and clearing them again afterwards is likely to outperform doing the operation on whatever subset of the warp is active at the call site, at least when pointers are uniform and so forth.

Leaving this issue as a reminder to look into this, fix it, then move libc back to using builtin_memset.

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Jon Chesterfield (JonChesterfield)

PR https://github.com//pull/143607 for libc replaces a builtin_memset with an open coded equivalent and reports substantial performance gains (and minor reg count increase). That shouldn't be possible.

memset (and memcpy, memmove etc) have completely specified semantics and intrinsics with alignment metadata and similar on them. The backend could be lowering those optimally. In particular, enabling inactive lanes in the exec mask and clearing them again afterwards is likely to outperform doing the operation on whatever subset of the warp is active at the call site, at least when pointers are uniform and so forth.

Leaving this issue as a reminder to look into this, fix it, then move libc back to using builtin_memset.

[jhuber6]

It makes it faster because we're deliberately parallelizing it in cases where the target pointer is uniform. Now, we could potentially do some uniformity analysis and use whole wave mode to do a much better version of this, but that'd be a lot of effort and only be wortwhile in cases where the number of bytes to set is more than 128 or so.

Also, specifically in this case, I have a bitmask that represents which lanes are uniform. That allows me to parallelize it in parallel. We could conceivably do that. (Maybe we should have an LLVM intrinsic for match_all?). Would probably always be faster in cases where the size is potentially large. We'd need to investigate WWM for compute though. I'm interested in turning that on for reductions as well.