llvm dev - Dec 2021 - Proposal: Introduce memory comparison intrinsics

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211122/fafda3c6/attachment.html>

> 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>

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>

Our main motivation is to have an atomic variant of memcmp. We discussed
extending the pattern matching and we may do it sometime later, but it's not
the first on our list.

Regarding non-standard signatures. I think it'd be worth to have an
'isVolatile' flag for non-atomic memcmp (like for memcpy). We cannot
pass this flag to a lib function call, so your suggested approach with
introducing new libfuncs wouldn't work.
Also introducing the memcmp intrinsic would make the code more consistent and
clearer to understand. memcpy, memset, memmove already have intrinsics and we
can share some intrinsics optimization. E.g., we could hoist memcpy and memcmp
of invariant arrays out of the loop using a generalized code for memory
intrinsics.

Dmitry

От: Philip Reames <listmail at philipreames.com>
Отправлено: Thursday, November 25, 2021 2:16 AM
Кому: Dmitry Makogon <dmakogon at azul.com>; llvm-dev at lists.llvm.org
Тема: Re: [llvm-dev] Proposal: Introduce memory comparison intrinsics


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<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/20211206/c5eb8ac7/attachment-0001.html>