[PATCH] D34885: Add element atomic memset intrinsic

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 6 16:22:33 PDT 2017


efriedma added a comment.

There's a lot of history going into this.

The memset API isn't really very good; memset is enshrined as an intrinsic most because it's available as part of the C library (and therefore well-optimized for most targets).  This saves us a bunch of work, and it's good enough for the most common case of initializing memory with an all-zero pattern.

The problem with adding a memset_pattern intrinsic is that we can't really support it well on all targets, at least not without a bunch of implementation work.  If we're going to emit a call, we need an implementation somewhere, which means we need to add one to compiler-rt, and probably write target-specific code to optimize it.  And even if we did have a good implementation for a bunch of targets in compiler-rt, people trying to use clang with libgcc or a freestanding target would complain about not having that implementation available.  So we have the current solution, where we don't have an intrinsic, and depend on vectorization/unrolling to generate reasonably fast code for initialization which can't be lowered to memset.

If you're writing a new API which isn't tied to the history of memset, the same interface doesn't really make sense; the only possible advantage is sharing code in the optimizer.  But maybe that's what we're stuck with; the potential advantages aren't important compared to the burden of implementing/maintaining an intrinsic with a different API.

---

On a side-note, it's sort of a problem for the other unordered-atomic intrinsics that we currently don't have an implementation available in compiler-rt... but we can let it slide for now because most languages don't use unordered atomics anyway.


https://reviews.llvm.org/D34885





More information about the llvm-commits mailing list