[RFC] memfill and memtransfer intrinsics for generalized memset/memcpy

[nikic]

I like the idea of a memfill intrinsic.

@efriedma-quic

For memfill, when selectiondag sees a “memfill” intrinsic, how do you expect it to lower it? Apple targets have memset_pattern4/8/16, but other targets don’t have any equivalent functionality. And if you try to just expand it to a simple loop (presumably in an IR pass just before SelectionDAG), the performance of that loop is probably not great; you need to vectorize/unroll/specialize on alignment/etc. to get decent performance. But if you try to do that inline, you start having codesize issues, so you probably need some number of out-of-line helper functions. None of this is really unsolvable, but your proposal doesn’t really describe how you plan to deal with it.

Since recently, PreISelIntrinsicLowering will lower large/unknown-size memcpy/memset to loops for targets that don’t support these libcalls. It would be straightforward to extend that to memfill for non-Darwin targets.

Regarding code size, I think the comparison point here is “the frontend directly emits the loop”, which is what would happen right now. In that case a loop legalization isn’t really worse than the current situation. Just need to be careful that intrinsic is costed appropriately.

---

I’m not a fan of the memtransfer proposal. Especially when I see this in conjunction with [RFC] Correct implementation of memcpy with metadata, which is a proposal in the same area, but the reverse goal, it seems like we should really be focusing on adding the byte type.