search for: freestand

(summarising IRC) Rethinking a little, I would be inclined to agree that combined hosted and freestanding modules should not be compiled in hosted mode. Here's one scenario where we may break: suppose I LTO-link an implementation of memset compiled with -ffreestanding with a program compiled with -fhosted. With the proposed rule, the loop idiom recognizer may transform the body of the memset fun...

...ric and Akira (for thoughts on module flags) > On 2016-Sep-16, at 12:47, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Sep 16, 2016, at 12:30 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> In PR30403 we've been discussing how to encode -ffreestanding when using LTO. This bit is currently dropped during LTO because its only representation is in the TargetLibraryInfo created by clang (http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258). >> >> The proposal is to introduce a module flag that we set in any translati...

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 too conservative. Currently -ffreestanding disables optimizing all builtin functions, just like -fno-builti...

In PR30403 we've been discussing how to encode -ffreestanding when using LTO. This bit is currently dropped during LTO because its only representation is in the TargetLibraryInfo created by clang ( http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258). The proposal is to introduce a module flag that we set in any translation unit compiled...

Hi, is there any documentation on which functions clang assumes to be provided by a freestanding environment? Are that really only memcpy, memmove, memset and memcmp? Greetings, Jan

On 18 Aug 2015, at 17:23, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Freestanding code is still documented to require memset and a few other > things. I had found a few messages mentioning that they are required when generating freestanding code with clang (and GCC), but nothing about llvm. Could you point me to that documentation so I know what I have to provide? Thanks...

...nk it is completely wrong for the verifier to be checking anything about calls to functions that happen to be called "malloc". What if I have my own runtime in which "malloc" is completely different to the usual one? From my reading of the gcc docs, malloc is not provided in a freestanding environment and thus cannot be assumed to be the normal malloc. I think this code should be removed from the verifier. Instead, isMalloc should also check the number of parameters and their types, as well as the return value. Actually isMalloc also seems bogus. In a freestanding environment...

...e big scalar for atomic/volatile ones. > Try to generate memcpy or memmove when possible ? Are memcpy/memmove guaranteed to be handled inline, i.e., without a call to libc? Or are there plans to do this in the context of the (afaik) long term goal of enabling llvm to (optionally) generate freestanding code? If not, generating memcpy/memmove seems like a bad idea, as it would make that goal harder to achieve. FWIW, personally I think that all accepted sizes should be handled reasonably efficiently (or, in other words, that other sizes should result in a compile time error). I hadn't...

...= > > PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); > Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI); > } Yes, I agree, the verifier shouldn't worry about malloc calls. > Actually isMalloc also seems bogus. In a freestanding environment > there is no reason that a function that happens to be called "malloc" > should have anything to do with memory allocation. Do you have a > plan to handle this? Shouldn't all malloc manipulations be done from > SimplifyLibcalls? We violate this in other...

New clang versions need the '-ffreestanding' flag because new changes convert system calls to their unlocked versions, which don't exist in the kernel library. Signed-off-by: Bill Wendling <morbo at google.com> diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc index f500d535..9cf4b2d9 100644 --- a/scripts/Kbuild.kli...

...cc generates llvm.memset, so this is not as visible. Also (I'm not sure about this) it may be that on some platforms gcc always expands builtin_memset into a code sequence rather than generating a call to the library memset function. However, gcc is not obliged to use a code sequence even in a freestanding environment. The environment is always required to provide memset. Here's what the gcc docs say: GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'. Ciao, Duncan.

...vm.memset, so this is not as visible.  Also (I'm not sure about this) > it may be that on some platforms gcc always expands builtin_memset into a > code sequence rather than generating a call to the library memset function. > However, gcc is not obliged to use a code sequence even in a freestanding > environment.  The environment is always required to provide memset.  Here's > what the gcc docs say: > >   GCC requires the freestanding environment provide `memcpy', `memmove', >  `memset' and `memcmp'. > > Ciao, > > Duncan. > ________________...

Hi, all, 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. In fact, I'm trying to compile newlibc with llvm, I do not need this kind of llvm functions. How can I remove them during the compilation? Best regards, -- Hao Shen

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, Thanks. I've emailed cfe-dev. We absolutely need clang/llvm to not insert the calls...

...or the verifier to be checking > anything > about calls to functions that happen to be called "malloc". What if I > have my own runtime in which "malloc" is completely different to the > usual one? From my reading of the gcc docs, malloc is not provided > in a freestanding environment and thus cannot be assumed to be the > normal malloc. What does the Ada front-end declare malloc as? > > I think this code should be removed from the verifier. Instead, > isMalloc should also check the number of parameters and their types, > as well as the return va...

...o this is not as visible. Also (I'm not sure about this) >> it may be that on some platforms gcc always expands builtin_memset into a >> code sequence rather than generating a call to the library memset function. >> However, gcc is not obliged to use a code sequence even in a freestanding >> environment. The environment is always required to provide memset. Here's >> what the gcc docs say: >> >> GCC requires the freestanding environment provide `memcpy', `memmove', >> `memset' and `memcmp'. >> >> Ciao, >> &g...

...d the latest NDK (r10) and compiled with the following cmd: >> arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0 >> It still produces assembly with a call to "memcpy". Maybe the -fno-builtin >> is broken also in the latest release. > It's not broken. Even freestanding implementation is supposed to > provide mem* functions. > It’s also supposed to be possible to write a memcpy() implementation in C without the compiler’s idiom recognizer just transforming it into a call to the system memcpy(). -fno-builtin is supposed to be how to do that, right? -jim

...t as visible.  Also (I'm not sure about this) >>> it may be that on some platforms gcc always expands builtin_memset into a >>> code sequence rather than generating a call to the library memset function. >>> However, gcc is not obliged to use a code sequence even in a freestanding >>> environment.  The environment is always required to provide memset.  Here's >>> what the gcc docs say: >>> >>>   GCC requires the freestanding environment provide `memcpy', `memmove', >>>  `memset' and `memcmp'. >>> &g...

I am compiling something without standard libraries, including no libc. Somehow, this bitcode is being generated by plain array manipulation code: %12 = add i8 %11, -19 %tmp35 = icmp sgt i32 %9, 1 %smax36 = select i1 %tmp35, i32 %9, i32 1 call void @llvm.memset.p0i8.i32(i8* getelementptr inbounds ([100 x i8]* @global_array_char, i32 0, i32 0), i8 %12, i32 %smax36, i32 1, i1 false)

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 emailing cfedev, not llvmdev. >>> >> >> Hi, >> >> Thanks...