similar to: RFC: Inline expansion of memcmp vs call to standard library

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

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

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.

Hello, I've made changes to the prologue to not spill callee saved gprs to the stack but rather spill them to unused vector registers. I'm not sure how to handle this in the cfi directives. Originally, we would use cfi_offset to give an offset of where it is saved on the stack. I tried to instead use the cfi_restore directive. As the docs say ".cfi_restore says that the rule

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

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

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?

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

Op 2014-06-12 om 06:43 schreef Geert Stappers: > 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 >

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

Hi, Look at the following code: Look at the following C code seqence: unsigned char mainGtU ( unsigned int i1, unsigned int i2, unsigned char* block) { unsigned char c1, c2; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; .. ..

My understanding is that dynamically linking should pose no problem, but I am no lawyer. On Linux, glibc is also under LGPL license, and LLVM usually links against it. (There is really no need for us to depend on libiconv. If it is deemed to risky, then I can dropped it.) From: Anton Korobeynikov <anton at korobeynikov.info> To: Kai Peter Nacke <kai.nacke at de.ibm.com> Cc:

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

On Fri, May 19, 2017 at 4:32 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > i think you'd have to write some idiom recognizer here. The ones we have > won't do it. > > I guess my other question would be how commonly this happens. If it's common > and matters a lot, awesome. > I wouldn't do it just to fix SPEC :P > > (people who

Hi! On z/OS, there is the need to convert strings from EBCDIC to UTF-8 and vice versa. Using the POSIX iconv functions has some challenges, so I created a small wrapper around this functionality to get the same result on all platforms. This functionality is required for reading and writing GOFF object files and can also be used in the frontend. I put up the code on Phabricator

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

Hello, I've noticed that finding disks by guid using chain.c32 from both 4.03 and latest 4.04 pre12 doesn't work as expected (unable to find requested GPT disk/partition). The entered guid is correct according to gdisk and chain.c32 debug information but still chain.c32 claims it can't find the drive. The bug is located in function find_by_guid, line 991. It is is_me =

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:

> On Feb 5, 2016, at 4:42 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Feb 5, 2016, at 2:43 PM, Anupama Chandrasekhar via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi: >> >> I have a question about the llvm StringSwitch class. Why is this more efficient than comparing the hashes of the strings or just