Chris Lattner via llvm-dev
2021-Nov-23 07:29 UTC
[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 <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20211122/e4d40fd7/attachment.html>
Dmitry Makogon via llvm-dev
2021-Nov-24 10:07 UTC
[llvm-dev] Proposal: Introduce memory comparison intrinsics
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<mailto: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<mailto: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/faf0e1db/attachment.html>