search for: freeinst

...happy if it got removed. Even if we keep it, malloc/alloca >>> should be extended to optionally take 64-bit sizes. >> >> I'm curious. Do we want to keep the free instruction? > > No, there's no reason to. There still are reasons to have it; just grep around for FreeInst. Function attributes are not yet sufficient to replace all of those yet. And if the ailgnment attribute on MallocInst were implemented, perhaps via posix_memalign or other target-specific mechanisms, then MallocInst would also have a reason to be kept. Dan

...aterworth wrote: > Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and > DisableSymbolSearching to cause malloc and free calls to be handled > by my logging functions. Sorry for the unnecessary list mail. No problem, this is a better way to go. The MallocInst and FreeInst instructions are about to be removed from LLVM IR. Malloc and free will be represented normal 'call' instructions. > Is it possible to find out the size and beginning pointer of the > current stack frame, from a function operating outside of the > virtual machine, but cal...

...we keep it, malloc/alloca >>>> should be extended to optionally take 64-bit sizes. >>> >>> I'm curious. Do we want to keep the free instruction? >> >> No, there's no reason to. > > > There still are reasons to have it; just grep around for FreeInst. > Function > attributes are not yet sufficient to replace all of those yet. > > And if the ailgnment attribute on MallocInst were implemented, perhaps > via posix_memalign or other target-specific mechanisms, then > MallocInst > would also have a reason to be kept. isa<F...

...ndbox based on llvm. In order to prevent programs from accessing memory that has not been allocated to them, I want to replace calls to malloc and free with calls to a logged functions that will record the memory that is being allocated to the program. Is it possible to cast/convert a MallocInst or FreeInst to a CallInst? Thanks, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091016/793e9d36/attachment.html>

Hi everyone, I noticed that MallocInst and FreeInst have been removed from the LLVM IR as well as the language reference[1]. May I propose that at least some placeholder is left in that document telling the reader that these instructions have been removed. This should be kept in at least until there is one official release that does not support...

...e: > > Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and > DisableSymbolSearching to cause malloc and free calls to be handled by my > logging functions. Sorry for the unnecessary list mail. > > > No problem, this is a better way to go. The MallocInst and FreeInst > instructions are about to be removed from LLVM IR. Malloc and free will be > represented normal 'call' instructions. > > Is it possible to find out the size and beginning pointer of the current > stack frame, from a function operating outside of the virtual machine, but &g...

...In > order to prevent programs from accessing memory that has not been allocated > to them, I want to replace calls to malloc and free with calls to a logged > functions that will record the memory that is being allocated to the > program. Is it possible to cast/convert a MallocInst or FreeInst to a > CallInst? > > Thanks, > > Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091016/c0d67813/attachment.html>

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not modify/access any memory location. Is that true ? If I have missed other instructions that could alter/modify memory, please let me know. Thanks for your time....

...till in the process of baking 2.7, what is the sanction way of doing heap allocation going forward? :-) Garrison On Dec 7, 2009, at 11:18, Chris Lattner wrote: > > On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: > >> Hi everyone, >> >> I noticed that MallocInst and FreeInst have been removed from the LLVM IR as >> well as the language reference[1]. May I propose that at least some >> placeholder is left in that document telling the reader that these >> instructions have been removed. This should be kept in at least until there is >> one off...

...Even if we keep it, malloc/alloca >>>>> should be extended to optionally take 64-bit sizes. >>>> I'm curious. Do we want to keep the free instruction? >>> No, there's no reason to. >> >> There still are reasons to have it; just grep around for FreeInst. >> Function >> attributes are not yet sufficient to replace all of those yet. >> >> And if the ailgnment attribute on MallocInst were implemented, perhaps >> via posix_memalign or other target-specific mechanisms, then >> MallocInst >> would also have a...

...Chris > >> >> Garrison >> >> On Dec 7, 2009, at 11:18, Chris Lattner wrote: >> >>> >>> On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: >>> >>>> Hi everyone, >>>> >>>> I noticed that MallocInst and FreeInst have been removed from the LLVM IR as >>>> well as the language reference[1]. May I propose that at least some >>>> placeholder is left in that document telling the reader that these >>>> instructions have been removed. This should be kept in at least until there...

On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: > Hi everyone, > > I noticed that MallocInst and FreeInst have been removed from the LLVM IR as > well as the language reference[1]. May I propose that at least some > placeholder is left in that document telling the reader that these > instructions have been removed. This should be kept in at least until there is > one official release th...

Is there a convenient way to access the arguments of an arbitrary instruction? The programmer's manual describes how to iterate over the values a given instruction uses, but that doesn't seem to be exactly the same thing. For instance, given a pointer to a FreeInst, how can I get the pointer that is freed? Or from a SetCondInst pointer, the two values that are compared in the appropriate order? Is iterating over the use-def chain the right way to do it, or am I missing something? Thanks, Scott Mikula

...way visible from the LLVM IR; I don't believe they'll take into account things like read/writes due to register spills created by the code generator. > (1) LoadInst : Ref > (2) StoreInst : Mod > (3) VAArgInst : Ref (?) > (4) AllocaInst : Mod > (5) MallocInst : Mod > (6) FreeInst : Mod > (7) CallInst : Mod/Ref ? > > Also, my earlier impression was that the GEP instruction only computes > the effective address and does not modify/access any memory location. > Is that true ? > This is correct. > If I have missed other instructions that could alter/mod...

...malloc and free, just like any external function. -Chris > > Garrison > > On Dec 7, 2009, at 11:18, Chris Lattner wrote: > >> >> On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: >> >>> Hi everyone, >>> >>> I noticed that MallocInst and FreeInst have been removed from the >>> LLVM IR as >>> well as the language reference[1]. May I propose that at least some >>> placeholder is left in that document telling the reader that these >>> instructions have been removed. This should be kept in at least >&g...

...er type), there is nothing to check. > Another question is: How much does Verifier.cpp check statically? > Can I take it as a type checker for SSA? Is there any static > semantics that has not been checked yet? The verifier is best effort, it does not guarantee correctness. > 2) visitFreeInst has been removed from lib/ExecutionEngine/Interpreter in 2.7 > Will this have any back-compatible problem when interpreting any > *.bc from 2.6? The .bc reader will eliminate freeinst from the ir when reading an old file. -chris

...Garrison >>> >>> On Dec 7, 2009, at 11:18, Chris Lattner wrote: >>> >>>> >>>> On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> I noticed that MallocInst and FreeInst have been removed from >>>>> the LLVM IR as >>>>> well as the language reference[1]. May I propose that at least >>>>> some >>>>> placeholder is left in that document telling the reader that these >>>>> instructions have...

...llvm/lib/Analysis/DataStructure/BottomUpClosure.cpp:109: warning: converting of negative value `-0x000000001' to `unsigned int' Compiling AliasSetTracker.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Analysis/AliasSetTracker.cpp: In member function `bool llvm::AliasSetTracker::add(llvm::FreeInst*)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Analysis/AliasSetTracker.cpp:260: warning: passing negative value `-0x000000001' for converting 2 of `llvm::AliasSet& llvm::AliasSetTracker::addPointer(llvm::Value*, unsigned int, llvm::AliasSet::AccessType, bool&)' /home/wandere...

...ID, LabelTyID, MetadataTyID and etc are ignored in the 'default' branch. Does it mean we dont need to check them? Another question is: How much does Verifier.cpp check statically? Can I take it as a type checker for SSA? Is there any static semantics that has not been checked yet? 2) visitFreeInst has been removed from lib/ExecutionEngine/Interpreter in 2.7 Will this have any back-compatible problem when interpreting any *.bc from 2.6? Thanks -- Jianzhou

LLVM build without big problems in obj dir == src dir case (for example, last night tester build) But I have problem with building CVS version LLVM in obj dir != src dir case. ======= Finished building ModuleMaker debug executable (without symbols) ======= gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/llvm/obj/examples/ModuleMaker' gmake[1]: Leaving directory