search for: memcmps

Hi, The dovecot 2.3.0.1 Debian package currently fails to build on all big-endian architectures[1], due to murmurhash3 tests failing. The relevant output from e.g. s390x is: test-murmurhash3.c:22: Assert(#8) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 test-murmurhash3.c:22: Assert(#11) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 test-murmurhash3.c:22:

...tr); switch (len) { case 2: if (std::memcmp(str, "de", 2) i = 1; else (std::memcmp(str, “qr", 2) i = 1; else i = -1; case 4: .. Which isn’t optimal perhaps, but isn’t bad either. The compiler should theoretically be able to do good things with back-to-back memcmps, but probably isn’t doing anything good there for long ones. Short memcmps should be turned into a load+compare, meaning they become another switch. -Chris

I propose a new intrinsic "llvm.memcmp" that compares a block of memory for equality (a subset of the libc behavior). Backends are free to use the alignment to optimize using wider than byte operations. Since the result is only equal/not-equal, byte order is not important. For languages that support array compares, this would be very useful. Syntax: declare i1 @llvm.memcmp(i8*

On Fri, Aug 20, 2010 at 1:03 PM, Bagel <bagel99 at gmail.com> wrote: > I propose a new intrinsic "llvm.memcmp" that compares a block of memory > for equality (a subset of the libc behavior).  Backends are free to use the > alignment to optimize using wider than byte operations.  Since the result is > only equal/not-equal, byte order is not important. > > For

...1; >> else (std::memcmp(str, “qr", 2) >> i = 1; >> else >> i = -1; >> case 4: >> .. >> >> Which isn’t optimal perhaps, but isn’t bad either. The compiler should >> theoretically be able to do good things with back-to-back memcmps, but >> probably isn’t doing anything good there for long ones. Short memcmps >> should be turned into a load+compare, meaning they become another switch. >> >> -Chris >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: &lt...

On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > Hi, > > The dovecot 2.3.0.1 Debian package currently fails to build on all > big-endian architectures[1], due to murmurhash3 tests failing. The > relevant output from e.g. s390x is: > > test-murmurhash3.c:22: Assert(#8) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > test-murmurhash3.c:22: Assert(#11)

Hi all, We'd like to suggest *adding a -memeq-lib-function* flag to allow the user to specify a `*memeq()*` function to improve string equality check performance. Right now, when llvm encounters a *string equality check*, e.g. `if (memcmp(a, b, s) == 0)`, it tries to expand to an equality comparison if `s` is a small compile-time constant, and falls back on calling `memcmp()` else. This is

If we are considering an optimization to convert calls to memcmp into bcmp, then does it make sense to add an intrinsic for bcmp like there is for memcmp? That way IR writers can express their requirements precisely: memcmp if you care about the direction of inequality, and bcmp if you do not. On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On 08/20/2010 04:06 PM, Eli Friedman wrote: > On Fri, Aug 20, 2010 at 1:03 PM, Bagel<bagel99 at gmail.com> wrote: >> I propose a new intrinsic "llvm.memcmp" that compares a block of memory >> for equality (a subset of the libc behavior). Backends are free to use the >> alignment to optimize using wider than byte operations. Since the result is >> only

Currently on PowerPC, calls to memcmp are not expanded and are left as library calls. In certain conditions, expansion can improve performance rather than calling the library function as done for functions like memcpy, memmove, etc. This patch (https://reviews.llvm.org/D28163) is an initial implementation for PowerPC to expand memcmp when the size is an 8 byte multiple. The approach currently

With the intrinsic support for ‘memcpy’ and ‘memset’ the operands also have associated alignment operands. I think that ‘memcmp’ should also provide the alignment information for each of the source operands (when statically known). In some cases this will lead to more optimal alignment aware lowering, and for targets for which unaligned access is costly or fatal, it can be lowered safely.

Can I make another suggestion: create an intrinsic for memory equality, e.g. llvm.memcmp_eq.p0i8.p0i8.i64(i8*a, i8*b, i64 len). This intrinsic would return zero if the memory regions are equal, and nonzero otherwise. However, it does NOT return any notion of "greater" or "less". Many applications require only determining equality, rather than a total ordering. Given that

Improving lowering for memcmp is definitely something we should do for all targets. Doing it in a target specific way is decidedly non-ideal. It looks like we already have some code in SelectionDAGBuilder which tries to optimize the lowering for the memcpy library call. I am a bit confused by the problem you are trying to solve. Are you specifically interested in lowering for constant

Hello, A `make efi32` yeilds me make[3]: *** No rule to make target `efi32/com32/lib/memcmp.o', needed by `syslinux.so'. Stop. make[3]: Leaving directory `efi32/efi' make[2]: *** [efi] Error 2 Output of `ls -Gl efi32/com32/lib/mem*.o`: -rw-r--r-- 1 stappers 2812 Jun 10 22:06 efi32/com32/lib/memcpy.o -rw-r--r-- 1 stappers 3620 Jun 10 22:06 efi32/com32/lib/memmem.o

Hi: I have a question about the llvm StringSwitch class. Why is this more efficient than comparing the hashes of the strings or just using a bunch of if statements. Anupama -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160205/9be0fcc8/attachment.html>

Op 2014-06-10 om 22:55 schreef Geert Stappers: > > Hello, > > A `make efi32` yeilds me > > make[3]: *** No rule to make target `efi32/com32/lib/memcmp.o', needed by `syslinux.so'. Stop. > make[3]: Leaving directory `efi32/efi' > make[2]: *** [efi] Error 2 It was encountered while doing `make`. The `make efi32` is just to faster reproduce the build

Hi Aki, On 15:55 Mon 26 Mar , Aki Tuomi wrote: > On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > > Hi, > > > > The dovecot 2.3.0.1 Debian package currently fails to build on all > > big-endian architectures[1], due to murmurhash3 tests failing. The > > relevant output from e.g. s390x is: > > > > test-murmurhash3.c:22: Assert(#8) failed:

Hi all, I'm working on a new pass to optimize comparison chains. Motivation Clang currently generates inefficient code when dealing with contiguous member-by-member structural equality. Consider: struct A { bool operator==(const A& o) const { return i == o.i && j == o.j; } uint32 i; uint32 j; }; This generates: mov eax, dword ptr [rdi] cmp eax,

Chris Lattner wrote: > On Apr 13, 2008, at 12:40 PM, Talin wrote: > > >> Since you have memcpy, memmove, and memset in there, I was wondering >> why >> memcmp wasn't there as well. It seems obvious - which makes me think >> that if it's not there, then there must be some reason for it. >> > > Why do you want it to be an intrinsic?

[I'm not online regularly, so don't include me in any replies. And I'm not sure if the vorbis or the flac list, or something else, is more suitable for the following, so bear with me] Moin, moin. I used a recent ogg123 to play back a FLAC file I had created, and saw it wasn't able to seek within the file. So, I thought to myself, why not try out an OggFLAC file, so I created