[llvm-dev] Proposal: Introduce memory comparison intrinsics

Philip Reames via llvm-dev
Wed, 24 Nov 2021 19:15:44 -0000

Glancing at the in-tree usage, it looks like we have decent support for
optimizing and lowering existing calls to bcmp/memcpy, but very little
in the way of pattern matching formation.  Are you planning on extending
the matching pieces?  Or is the primary intent to be able to share
lowering code for the atomic invariants?

One thing I note is that glancing at existing code, it looks like not
all targets support bcmp or memcmp.  Given that, any intrinsic formation
is going to have to remain dependent on the appropriate TLI checks.
That's slightly odd, but not a show stopper.

I would find this proposal more compelling if you could show benefit to
the existing lowering/transformations by introducing the non-standard
signatures.  I don't see any obvious ways to do so, but maybe give that
some thought?

The major alternative to this proposal would be to simply add two new
libfuncs for the atomic variants of bcmp/memcpy, and then configure them
to be not-present on most targets.  This would allow you to reuse the
lowering code - which I do think is entirely reasonable for upstream -
without the need for the intrinsics.

Overall, I think this proposal is reasonable.  I'm not strongly in
support given the ease of the libfunc approach, but I don't really see
any serious downsides to it either.

Philip

On 11/22/21 8:22 AM, Dmitry Makogon via llvm-dev wrote:
>
> Hello everyone.
>
> I would like to introduce new intrinsics for memory comparison:
>
> memcmp - an equivalent of libc' memcmp,
>
> bcmp - an equivalent of libc' bcmp,
>
> memcmp.element.unordered.atomic - an element atomic version of memcmp,
>
> bcmp.element.unordered.atomic - an element atomic version of bcmp.
>
> Currently there exist some optimizations for memcmp/bcmp libc calls.
>
> We would like to have these optimizations for element atomic
> comparisons (atomicity permitted).
>
> I suggest we rewrite the existing optimizations to work with on new
> intrinsics and transform
>
> memcmp/bcmp libc calls to the corresponding intrinsics. This is
> similar to what we do with
>
> memcpy library calls.
>
> Having these optimizations work on intrinsics and not on recognized
> libc calls
>
> will allow us to share some existing transforms between atomic and
> non-atomic variants.
>
> I propose the following plan for introducing the new intrinsics:
>
> 1. Introduce non-atomic memcmp and bcmp intrinsics.
>
> 2. Reimplement existing transforms for non-atomic memcmp intrinsic,
>
> the same way as it's done for memcpy.
>
> 3. Introduce atomic intrinsics and reuse the optimizations.
>
> Please express your concerns about this.
>
> Dmitry
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211124/3cb438aa/attachment.html>