search for: memcmp

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: Assert(#12) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 murmurhash3 (murmurhash3_32) ..........................

...ficient than comparing hashes, and I'd be reluctant to collisions anyway). Now since you mentioned a "bunch of if statements" you can get very close. > StringSwitch is caching the length of the string to compare and first checking the length before doing the actual comparison using memcmp. So the two constructs below it should be equivalent: > > int i = StringSwitch<int>("abc").case("de", 1).case("fghi", 2).case("jkl", 3).default(-1); > > and: > > int i; > const char *str = "abc"; > int len = strlen(s...

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

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 languages that support array...

...l cause the 3 function calls to "Case()" and 1 to "Default()", Even if > the functions were inlined I would perform an if(!Result) check though > Result has been found, however if I were to code the same as: > > int len = strlen(str); > if(len == 2 && std::memcmp(str, "de", 2) { > i = 1; > } else if(len == 4 && std::memcmp(str, "fghi", 4) { > i = 2; > } else if(len == 3 && std::memcmp(str, "jkl", 3) { > i = 3; > } else { > i = -1 > } > > I would be performing only one if...

....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) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > test-murmurhash3.c:22: Assert(#12) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > murmurhash3 (murmurhash3_32) ...........

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 sub-optimal because memcmp has to compute much more than equality. We propose adding a way for the user to specify a `memeq` library function...

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

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 equal/not-equal, byte order is not important. >> >> For language...

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

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. MartinO From:...

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

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

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 error. > Output of `ls -Gl efi32/com32/lib/mem*.o`: > > -rw-r...

...los 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) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > > test-murmurhash3.c:22: Assert(#12) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > > murmurhash3 (murmurhas...

...mov eax, dword ptr [rdi] cmp eax, dword ptr [rsi] jne .LBB0_1 mov eax, dword ptr [rdi + 4] cmp eax, dword ptr [rsi + 4] sete al ret .LBB0_1: xor eax, eax ret I’ve been working on an LLVM pass that detects this pattern at IR level and turns it into a memcmp() call. This generates more efficient code: mov rax, qword ptr [rdi] cmp rax, qword ptr [rsi] sete al ret And thanks to recent improvements <https://reviews.llvm.org/D28637> in the memcmp codegen, this can be made to work for all sizes. Impact of the change I’ve...

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? What does that provide? > I can't really answer that question, since I don't kn...

...y out an OggFLAC file, so I created one, using `flac --ogg', rather than oggenc or something else. That ogg123 wasn't able to recognize the file as something it should have been able to chew on. So I dirtied myself in the source code and found the following: if (len >= 32 && memcmp(buf, "OggS", 4) == 0 && memcmp(buf+28, "fLaC", 4) == 0) return 1; /* Ogg FLAC */ Hmmm. That's sorta like my fresh file from somewhat recent source, but not quite: 00000000 4f 67 67 53 00 02 00 00 00 00 00 00 00 00 3d 59 |OggS..........=Y| 000...