similar to: [LLVMdev] variable size alloca

I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a function f(), that I've written, is defined as a global function (text) object, i.e., llvm-nm shows it marked with a 'T'. I have converted x.bc to an executable with the following command: llvm-ld -native -o x.exe x.bc When I run nm on x.exe, it shows that f is now a local function (text) object, i.e., nm

I am writing a transformation that needs to add a call to a function F() at the beginning of main() with the addresses of argc and argv as parameters to F(). However, the bytecode file I'm transforming has not allocated space on the stack for argc and argv. So, I developed my transformation to change main() from: ----- int main(int %argc, sbyte** %argv){ entry: ... // some use of

As a follow up, if I first convert x.bc to a c file using llc -march=c -o x.c x.bc, and then I use normal gcc to convert x.c to an executable, f() remains a global symbol. Is llvm-nm incorrectly converting the global symbols to local symbols? Ryan M. Lefever wrote: > I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a > function f(), that I've written, is

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

After looking at this problem longer, I believe that there is something wrong with the disassembler. When I run my transformation and then disassemble the output, I get bytecode that looks like: ----- int %main(int %argc, sbyte** %argv) { entry: alloca int ; <int*>:0 [#uses=3] alloca sbyte** ; <sbyte***>:0 [#uses=3] store int %argc,

Hello, Ryan. > It seems as though, when the bytecode is disassebled, the result of the > allocas should be given as a parameter to the stores. It's given. > If the disassembler doesn't give the allocas a name, then that dependency is > not conveyed. Both disassembly & bytecode is correct. Please carefully read LLVM Language reference about %"num" names. --

> Why isn't llvm giving a name to the value returned by the allocas and > using it in the store instructions? Because you pass in an empty string for the name in the new AllocaInst calls below. Replace the empty strings with "argc_addr" or whatever you want. > AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "", >

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

> How is c's const keyword translated when compiling c into > llvm bytecode. It isn't. You can verify this quite simply with the following test program: void a(const void *p) { } void b(void *p) { } $ clang --emit-llvm test.c ; ModuleID = 'foo' define void @a(i8* %p) { entry: %p.addr = alloca i8* ; <i8**> [#uses=1] %allocapt = bitcast

Can I specify passes that I want run directly to llvm-gcc? I don't want all of -O3, for example. I tried llvm-gcc -raiseallocs ..., but that didn't work. I also tried running cc1 directly and it didn't take -raiseallocs as a parameter either. Duncan Sands wrote: > On Tuesday 28 April 2009 04:02:47 am Ryan M. Lefever wrote: >> I assume that when -O3 (or O2 or O1) is

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

To create a stack based (local) 64 bit integer in LLVM IR, I used: Value *var = builder.CreateAlloca(Type::getInt64Ty(Ctx)); I wish to pass this variable to a function "void foo(unsigned long)". I created the signature of function foo() as follows: Constant *func = M->getOrInsertFunction("foo", Type::getVoidTy(Ctx),Type::getInt64Ty(Ctx), NULL); To pass the newly created

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"

I have a bitcode file Y that has a symbol __isoc99_fscanf in it. When I disassemble the bitcode, the symbol is written as "\01__isoc99_fscanf". I am wondering where this symbol is coming from? I grep'ed throughout /usr on my machine for both names, and I only found __isoc99_fscanf, without the special character in front. Regardless of where the symbol is coming from, I am

I have some code I am compiling with LLVM, and some functions in the code are begin declared as variable argument functions with no named arguments when the functions have known types. For example, the following C code uint64_t getStartTime(); is getting compiled to declare i64 @getStartTime(...) in bitcode. Why would this happen? Regards, Ryan

I have a problem. I'm writing a C compiler in my favorite programming language (don't ask :-) I have made a .s file, which can be correctly assembled and run with lli. But when I optimize it I get no errors from the optimizer, but the resultant file is incorrect. Here's what happens: llvm-as test2_gen.s %% no errors test2_gen.s.bc is produced lli test2_gen.s.bc n=887459712

I am trying to upgrade to the latest version of LLVM from svn. My transformations compile correctly, but when I go to run them I get a symbol lookup error. In particular, I have 2 libraries that I compile for use with opt called libaux.so and libmyxform.so. libaux.so implements functions that are used by libmyxform.so. When I run: ------- /llvm/bin/opt

Hi, I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. int func() { const int *arr; arr[0] = 1; } $ llvm-gcc main.c -c; echo $? 0 $ gcc main.c -c main.c: In function 'func': main.c:4: error: assignment of read-only location The difference disappears when arr[0] is replaced by *arr. (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't

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]

This certainly doesn't occur in gcc mainline. In fact, I improved the error message, and added a error test to gcc just yesterday. On 8/9/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 8 Aug 2007, Nikhil A. Patil wrote: > > I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. > > Looks like a bug, please file a bugzilla entry. >