[llvm-dev] Proposal: Introduce memory comparison intrinsics

[Guillaume Chatelet via llvm-dev]

I'm personally in favor of having consistent intrinsics for all libc memory
operations.

Beware that C doesn't guarantee 4 bytes int (could be 2 bytes), same for
the count parameters (size_t could be 4 or 8 bytes) so the signature is
target dependent.

On Wed, Nov 24, 2021 at 11:07 AM Dmitry Makogon via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I propose they have signatures similar to non-atomic/atomic llvm.memcpy:
> llvm_i32_ty llvm.memcmp (llvm_anyptr_ty %lhs, llvm_anyptr_ty %rhs,
> llvm_anyint_ty %length, llvm_i1_ty %is_volatile),
> llvm_i32_ty llvm.bcmp (llvm_anyptr_ty %lhs, llvm_anyptr_ty %rhs,
> llvm_anyint_ty %length, llvm_i1_ty %is_volatile),
> llvm_i32_ty llvm.memcmp.element.unordered.atomic (llvm_anyptr_ty %lhs,
> llvm_anyptr_ty %rhs, llvm_anyint_ty %length, llvm_i32_ty %element_size),
> llvm_i32_ty llvm.bcmp.element.unordered.atomic (llvm_anyptr_ty %lhs,
> llvm_anyptr_ty %rhs, llvm_anyint_ty %length, llvm_i32_ty %element_size).
>
> Having such signatures, it’s easy to transform the libc calls to the new
> intrinsics.
>
> Our main motivation for having these intrinsics is that we want to have an
> atomic memory comparison semantics, which we can’t express through a libc
> call.
> And if we are to add an atomic memcmp intrinsic, it’d natural to transform
> libc calls to intrinsics and we’d have some common logic work for all these
> functions.
>
> Dmitry
>
>
>
> *От:* Chris Lattner <clattner at nondot.org>
> *Отправлено:* Tuesday, November 23, 2021 2:29 PM
> *Кому:* Dmitry Makogon <dmakogon at azul.com>
> *Копия:* llvm-dev at lists.llvm.org
> *Тема:* Re: [llvm-dev] Proposal: Introduce memory comparison intrinsics
>
>
>
>
>
>
>
> On Nov 22, 2021, at 6:22 AM, Dmitry Makogon via llvm-dev <
> llvm-dev at lists.llvm.org> 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).
>
>
>
> Could you elaborate on the specific signatures these intrinsics would have?
>
>
>
> llvm.memcpy and friends exist because we want to capture additional
> semantics beyond what the memcpy signature does - notably alignment
> information.  What is all the additional information are you planning to
> capture for these?
>
>
>
> -Chris
>
>
>
>
>
>
>
> 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
>
>
> _______________________________________________
> 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/82c0d316/attachment.html>