similar to: [LLVMdev] Is there a reason why memcmp isn't an intrinsic?

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

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?

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

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

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.

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

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

Hi Hao Shen, > I am using llvm-gcc --emit-llvm to generate byte code. With llvm > readable ll format, I found some standard C library function such as > llvm.memset. this is not a C library function, it is an LLVM intrinsic. An intrinsic is analogous to a builtin in gcc. An intrinsic may be expanded out into a code sequence by the compiler, or may get turned into a library call (which

Thanks a lot for your answer. As what you said, I can not have any options to avoid generating this kind of intrinsic for byte code. Is it possible to modify gcc and ask it take all memset liked functions as a general function call? I know this solution is less performance efficient, but I would like to have it for my llvm assembly level modification works. But anyway, thanks for you help. Hao

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

On Tue, May 29, 2012 at 8:46 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > How do I disable that feature? I've tried -fno-builtin and/or > -ffreestanding > > with no success. > clang (as well as gcc) requires that freestanding environment provides > memcpy, memmove, memset and memcmp. > > PS: Consider emailing cfedev, not llvmdev. > Hi,

On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote: > >> How does this affect freestanding implementations? > > This transform is disabled with -fno-builtin or -ffreestanding. Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is

SHEN Hao wrote: > Thanks a lot for your answer. > As what you said, I can not have any options to avoid generating this kind > of intrinsic for byte code. Is it possible to modify gcc and ask it take > all memset liked functions as a general function call? I know this solution > is less performance efficient, but I would like to have it for my llvm > assembly level modification

Before I go writing a bug report, I want to know if the behavior I am seeing is intended. Before 1.3, I was able to generate a linkonce definition in one module, and an external declaration in another module and link them together, with the result being a defined symbol with external linkage. However, with the latest head, it apparently discards the linkonce version, and my output contains

On Tue, May 29, 2012 at 9:16 PM, Chandler Carruth <chandlerc at google.com>wrote: > > How do I disable that feature? I've tried -fno-builtin and/or >>> -ffreestanding >>> > with no success. >>> clang (as well as gcc) requires that freestanding environment provides >>> memcpy, memmove, memset and memcmp. >>> >>> PS: Consider

On Mon, May 10, 2010 at 7:19 PM, John Criswell <criswell at uiuc.edu> wrote: > SHEN Hao wrote: >> Thanks a lot for your answer. >> As what you said, I can not have any options to avoid generating this kind >> of intrinsic for byte code. Is it possible to modify gcc and ask it take >> all memset liked functions as a general function call? I know this solution

> How do I disable that feature? I've tried -fno-builtin and/or -ffreestanding > with no success. clang (as well as gcc) requires that freestanding environment provides memcpy, memmove, memset and memcmp. PS: Consider emailing cfedev, not llvmdev. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University