search for: disableallfunctions

Hi, I have finished migrating all of the simplify-libcalls pass functionality into instcombine and functionattrs. Now I am ready to completely to remove what is left of the pass from the source tree. However, there are a few C API functions for creating and managing the pass: /** See llvm::PassManagerBuilder::DisableSimplifyLibCalls */ void

Hi Meador, > I have finished migrating all of the simplify-libcalls pass > functionality into instcombine > and functionattrs. Now I am ready to completely to remove what is > left of the pass from > the source tree. However, there are a few C API functions for > creating and managing > the pass: > > /** See llvm::PassManagerBuilder::DisableSimplifyLibCalls */

...uiltin_foo to have the builtin behavior). This, again, is not possible with the existing 'nobuiltin' attribute, due to the function pointer problem. Instead, Clang currently just provides -fno-builtin, and even *that* only provides a broken half-implementation -- it calls TargetLibraryInfo::disableAllFunctions, whose effect is not preserved across "clang -fno-builtin -emit-llvm | opt", nor across LTO. There are several problems in this space. While your new attribute may be useful to help in this area, it is definitely not sufficient to solve the problem. -fno-builtin-strlen should disable t...

...uiltin_foo to have the builtin behavior). This, again, is not possible with the existing 'nobuiltin' attribute, due to the function pointer problem. Instead, Clang currently just provides -fno-builtin, and even *that* only provides a broken half-implementation -- it calls TargetLibraryInfo::disableAllFunctions, whose effect is not preserved across "clang -fno-builtin -emit-llvm | opt", nor across LTO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130516/cf7faa57/attachment.html> -------------- next p...

On May 15, 2013, at 10:32 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>> Initially, I'm just concerned about keeping the optimizations we already perform, such as globalopt lowering a new/delete pair into a global, while disabling the non-conforming variations of those optimizations. But we're also permitted to merge multiple allocations into one if they have

I'm trying to figure out exactly how the intrinsics/libc/libm work in llvm. For example, this code return user defined function: float acos(float x, float y) { return x+y; } float a; void foo(float b, float c) { a = acos(b, c); } But this code returns llvm.intrinsic: float acos(float, float); float a; void foo(float b, float c) { a = acos(b, c); } float acos(float x, float y) {

Hi Chris, > For now I've added a flag to MDA such that malloc clobbers rather than > resolving to undef; however I was wondering if there is a "proper" way to do > this with any compiler targeting LLVM? Clang has an option "-fno-builtin" that disables such assumptions (by adding the attribute "nobuiltin" to the relevant callsites by the looks of it). Is

...ribute "nobuiltin" to the relevant callsites by the > looks of it). Is that useful to you? That works; unfortunately I was using Dragonegg and would rather not switch at this point. For the benefit of Googlers, it appears that Clang -fno-builtin leads to a call to TargetLibraryInfo::disableAllFunctions, but Dragonegg-3.2 never calls it. However Dragonegg-3.3 /does/ honour the GCC -fno-builtin flag (diff here: http://llvm.org/viewvc/llvm-project?view=revision&revision=179666). This is a little blunt for my purposes -- I only need to disable malloc for this purpose, but it suffices. (Side...

Hello; I was trying to use the computeArraySize() function from the MemoryBuiltins.cpp file. It requires two arguments DataLayout *TD and const TargetLibraryInfo *TLI. Can anyone tell me how to get the TargetLibraryInfo? I am getting the DataLayout using: DataLayout *TD; TD = new DataLayout(&M); I hope that's the right way of getting it. Thanks a lot; -- Arnamoy Bhattacharyya

Hi, I'm using uclibc built with dragonegg-3.2 / gcc-4.6, and ran into a problem in which: * uclibc's realloc malloc()'s some memory * realloc then uses (malloc'd pointer) - some offset to find the true size allocated. * MemoryDependenceAnalysis (MDA) regards load from (malloc() call + any offset) to be undefined, and replaces the size read with 0. * All manner of chaos results

...e an instance of TargetLibraryInfo (an example is in > tools/opt/opt.cpp), and either use: > - setUnavailable(LibFunc::acos): this marks acos as "unavailable", > preventing optimizations from making assumptions about its behavior. > Equivalent to clang -fno-builtin-acos > - disableAllFunctions(): this marks all known functions as > unavailable. Equivalent to clang -fno-builtin > > > I'm also curious how LLVM handles pure functions in regards to > > optimizations. For example, libm functions such as acos. > > Note that I don't think libm functions are pure...