similar to: [LLVMdev] Getting TargetData and TargetLibraryInfo for determining Malloc size

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

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, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

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

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

On May 16, 2013, at 12:36 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > > Since it would probably help to quantify the complexity increase, I've implemented my more recent suggestion (patch attached). This patch allows 'nobuiltin' on a function declaration or definition, and adds a 'builtin' attribute which can only be present on a call site for a

On Thu, May 16, 2013 at 10:13 AM, Chris Lattner <clattner at apple.com> wrote: > 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

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

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

I had this on my TODO list for a while, but the recent introduction of inaccessiblememonly makes it suddenly more urgent, as there is a risk to waste effort in duplicated work and/or end up with suboptimal solutions. I collected 2 use cases for inaccessiblememonly : - Allocation like functions. - Runtime functions for managed languages, that touch state that the program itself can never touch

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

Thanks. isFreeCall() works well but for %call2 = call i32 bitcast (i32 (...)* @free to i32 (i8*)*)(i8* %call1) nounwind, !dbg !16 So I tried to figure out when the above instruction occurred. When <stdlib.h> is included, free(buf2R1); turn into call void @free(i8* %call1) nounwind, !dbg !16 when I forget to include <stdlib.h>, free(buf2R1); turn into %call2 = call i32 bitcast (i32

Hi, My apologies if this appears to be a very trivial question -- I have tried to solve this on my own and I am stuck. Any assistance that could be provided would be immensely appreciated. What is the absolute bare minimum that I need to do to disassemble an array of, say, ARM machine code bytes? Or an array of Thumb machine code bytes? For example, I might have an array of unsigned chars -- how

On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Nuno and Arnold: > > Thank you all for the input. > > Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. > A clique is statically or dynamically allocated type-free stretch of memory. A "clique" > 1) is maximal in the sense

Hi All, While trying to put together an MC-based assembler the other day, I again encountered MC's non-obvious memory ownership rules. The most egregious example of these is MCObjectStreamer's destructor: MCObjectStreamer::~MCObjectStreamer() { delete &Assembler->getBackend(); delete &Assembler->getEmitter(); delete &Assembler->getWriter(); delete Assembler;

Hamid 2C wrote: > Hi all, > > I am working on some old code which was compiled against llvm-2.5. > Anyway, in some places I, AllocationInst is used (e.g. to ensure the > instruction's type). Even in your current documentation > (http://llvm.org/docs/ProgrammersManual.html), I found an example that > uses this instruction. > If I got it correctly, this istruction

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

While this is target information, it isn't actually part of the target today and doesn't use any part of the target code. Maybe some day we can use a target hook to initialize the data structures, but even then I feel like this really belongs in the core analysis library. Would there be any objections to just moving it into Analysis? Doing this would remove a seriously ugly layering