similar to: [LLVMdev] 32 bit array size to malloc

On Jun 11, 2008, at 2:38 PM, Ryan M. Lefever wrote: > In the C documentation on linux, malloc is defined to take a size > parameter of type size_t. On my 64-bit linux machine, size_t turns > out > to be a 64-bit type. In LLVM, AllocationInst's require the array size > passed to them to be a 32-bit type. Is there a reason that LLVM's > intermediate representation

> No, there is no good reason. Like GEP, malloc and alloca should allow > the size to be either i32 or i64. Why not allow any integer type? Wouldn't that make things more uniform? D.

Consider the following c code: #include <stdlib.h> int main(int argc, char** argv){ if(malloc(sizeof(int)) == NULL){ return 0; } else{ return 1; } } When I compile it with -O3, it produces the following bytecode: define i32 @main(i32 %argc, i8** %argv) { entry: ret i32 1 } Is this an error? It should be possible for malloc to return NULL, if it can not allocate more

I am writing some code to identify malloc instructions with constant request sizes and to determine the request size if it is constant. I have two questions. 1) If a malloc is for an array allocation and the array size is a ConstantExpr, how can I obtain the value of the ConstantExpr? 2) I am using the following logic to determine if the malloc is for a constant request size and to

Ryan M. Lefever wrote: > I am writing some code to identify malloc instructions with constant > request sizes and to determine the request size if it is constant. I > have two questions. > > 1) If a malloc is for an array allocation and the array size is a > ConstantExpr, how can I obtain the value of the ConstantExpr? > The only way I know of is to determine what type

Hi, I'm currently implementing some optimization passes for LLVM and I came across a problem. I'm new to LLVM so if this question has been asked before please kindly tell me where can I find the answer. There are 2 types of AllocationInst - Alloca and Malloc. But most of the time from the compiled byte code I can only find the Alloca statement (actually I never come across a

To what do variable size LLVM alloca instructions get translated, when they are turned into machine code? I compiled a piece of code to bitcode and disassembled it. The disassembled code showed that there were alloca instructions with variable-sized parameters within the bitcode. When I turned the bitcode into machine code, I performed an nm on the result but didn't see any symbols

On Apr 30, 2008, at 2:10 PM, Ryan M. Lefever wrote: > Consider the following c code: > > #include <stdlib.h> > > int main(int argc, char** argv){ > if(malloc(sizeof(int)) == NULL){ return 0; } > else{ return 1; } > } > > > When I compile it with -O3, it produces the following bytecode: > > define i32 @main(i32 %argc, i8** %argv) { > entry: >

I am writing a pass where I need to make a function deceleration for printf. Below is the code I'm trying to use. ----- bool MyPass::runOnModule(Module &m) { vector<const Type*> args; args.push_back(PointerType::get(Type::SByteTy)); Function* f = m.getOrInsertFunction("printf", FunctionType::get(Type::IntTy, args, true)); ----- When I insert a call

How is c's const keyword translated when compiling c into llvm bytecode. I'm specifically interested in const pointer function arguments. Consider a function declared as follows in c: void f(const int* arg); When I examine f in llvm bytecode, how can I tell that arg is a pointer, whose contents can only be read, not written. Regards, Ryan

I don't mean to be a pain, but I was thinking about this a bit more. Does gcc ignore the const keyword? If not, why has LLVM chosen to deviate from gcc with respect to the const keyword? If so, then why do we bother using const in LLVM API code? I'm just curious and wanted to understand the thinking behind not preserving const. Thanks, Ryan Chris Lattner wrote: > This property

Ok, I think I figured it out. I talked to someone, and we figured out that when I make a call to printf with a constant string, I need to make a global variable and use getElementPtr to reference it. The modified call for accessing the printf is: /* m is Module*, f is Function*, i is Instruction* */ Constant* constStr = ConstantArray::get("test\n"); GlobalVariable* gv =

I don't follow what you mean - gcc doesn't ignore const and llvm doesn't deviate from gcc nor from the relevant language standards. Note that if you declare a global as const that we do capture this in the ir - what specifically do you want? Please provide an example. -Chris http://nondot.org/sabre http://llvm.org On Aug 14, 2007, at 11:58 PM, "Ryan M. Lefever"

Daveed: Perhaps I am looking at the wrong version of the specification. Section 5.1.2.3 appears to refer to objects having volatile-qualified type. The type of malloc() is not volatile qualified in the standard library definition. In general, calls to procedures that are outside the current unit of compilation are presumed to involve side effects performed in the body of the external procedure

Does llvm-gcc support the -fPIC option? I am using LLVM on both 32 bit linux and 64 bit linux, if that matters. Regards, Ryan -- Ryan M. Lefever [http://www.crhc.uiuc.edu/~lefever/index.html]

If <NumElements> is zero, what is the behavior of malloc() and alloca()? Can I call free() using the pointer that malloc() returns? Also, I'm assuming that free()ing a null pointer is a legal NOP? Regards, Jon

I am trying to use LLVM as a source to source C compiler. I use llvm-gcc to convert file.c->file.bc. Then I use opt to run my own compiler passes to convert file.bc->file.opt.bc. Then I use llc to convert file.opt.bc->file.opt.c. Now, I want to use normal gcc to compile file.opt.c into an executable. However, I'm getting the following errors: test.opt.c:89: warning:

This property isn't preserved on the llvm ir, because const can always be cast away. If you want mod information, then I suggest using the aliasanalysis interface to get mod ref info for a call. -Chris http://nondot.org/sabre http://llvm.org On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever" <lefever at crhc.uiuc.edu> wrote: > How is c's const keyword translated

On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > If <NumElements> is zero, what is the behavior of malloc() and > alloca()? > Can I call free() using the pointer that malloc() returns? alloca is not standard. The behavior of malloc is covered in 7.20.3p1: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or

This has been reported. http://llvm.org/bugs/show_bug.cgi?id=1317 On 4/10/07, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > > I checked out llvm from cvs & llvm-gcc from svn last night and again > tonight. Each time they compiled and installed fine. After installing > them, I recompiled compiler transforms I had written for opt. opt seems > to load the my