similar to: [LLVMdev] bytecode to c conversion

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:

I am trying to disassemble some bytecode using llvm-dis: llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc However, I am getting the following error. llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) How do I go about figuring out what the problem is? llvmtest/sliceme2.cbc is newly compiled using the same version of llvm-gcc as llvm-dis. -- Ryan M. Lefever

I am still diagnosing the cause of the assertion failure and will submit a bug when I better understand the problem. Reid Spencer wrote: > Ryan, > > This looks like a bug. Could you file it, please? > > Reid. > > On Thu, 2007-02-22 at 19:47 -0600, Ryan M. Lefever wrote: > >>I have a compiler transform that I have been working on that produces >>bytecode

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

On Fri, 2007-04-06 at 14:27 -0500, Ryan M. Lefever wrote: > Is a PR a bug report on the bugzilla database? Yes, so named because of the URL translation. I.e. http://llvm.org/PR123 takes you to bugzilla bug 123. PR == Problem Report. > I am also running > bugpoint to see if that yields anything. Okay, good. That might turn up something useful. If you suspect its a bug, please file

Is a PR a bug report on the bugzilla database? I am also running bugpoint to see if that yields anything. Reid Spencer wrote: > Hi Ryan, > > On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > >>I am running the following llvm-ld command to produce native code: >> >>llvm-ld -native -o code.exe code.bc -lm >> >>However, I am getting the

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

I get a similar error when I try to disassemble a bytecode file generated by llvm-gcc released for llvm 1.9. Do I need to upgrade to a new llvm-gcc? Ryan M. Lefever wrote: > I am trying to use llvm-ld but when I try to link several bytecode files > into a single bytecode file, it gives me the following error: > > llvm-ld -o benchmarks/bc-1.06/src/bc.c.bc

Hi Ryan, On Fri, 2006-12-01 at 18:06 -0600, Ryan M. Lefever wrote: > I am trying to disassemble some bytecode using llvm-dis: > llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc > > However, I am getting the following error. > > llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) The problem is most likely that sliceme2.cbc is *not* bytecode. Open the

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if

Thank you for the help. There seem to be several things in my makefiles that are messed up as a result of switching from the gcc3.4 front end to the gcc4 frontend. Is there any documentation listing the things that have changed? Thanks, Ryan Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever] On Fri, 1 Dec 2006, Reid Spencer wrote: > Hi Ryan, > > On Fri, 2006-12-01 at 18:06

I followed what you said and called verifyModule() with the AbortProcessAction option. verifyModule() returns false, but does not abort and does not print out any information about what caused the verification to fail. Chris Lattner wrote: > On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >> I am writing an interprocedural compiler pass. Because the passneeds >> information from a

Ryan M. Lefever wrote: > 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

Thank you for the response. I guess the only thing that is confusing is that the LLVM documentation, at http://llvm.org/docs/Projects.html under the "Create a Project from the Sample Project" heading, indicates that (1) you can place your project *anywhere* you want, and (2) that you are supposed to use the AutoRegen.sh script as is. However, that seems not to be the case. The

I didn't see anything on http://llvm.org/SVNMigration.html, but I'm assuming that llvm/projects has moved to llvm/examples. Is that correct? If so the documentation in http://llvm.org/docs/GettingStarted.html will need to be updated. In particular, the getting started doc talks about checking out llvm-test to llvm/projects. Also, I'm curious why the llvm/projects/sample

Ryan, This looks like a bug. Could you file it, please? Reid. On Thu, 2007-02-22 at 19:47 -0600, Ryan M. Lefever wrote: > I have a compiler transform that I have been working on that produces > bytecode that passes the verifier. However, when I try to read that > bytecode back in, I get the assertion failure below. > > llvm::BytecodeReader::ParseConstantPoolValue(unsigned

Reid, Thanks for the help. I am trying out the fixes you checked into CVS. I seem to be getting some errors running AutoRegen.sh. I am a bit inexperienced with autoconf and m4. The errors I'm getting are below. Do you know what the problem is? I am using machines running FC3. The autoconf version is 2.59, the aclocal version is 1.9.2, and the m4 version is 1.4.1.

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

Thanks for the help Reid! I frequently look at the online doxygen, but sometimes its difficult to determine the correct replacement when a method is removed from LLVM. In this particular case, I knew which new CallInst constructor to use, I just couldn't figure out the proper syntax. At any rate, I really appreciate your help!! Reid Spencer wrote: > On Tue, 2007-03-06 at 22:44 -0600,

When I use LLVM to translate bytecode to C, it seems to stick its own definitions of several glibc calls like strcpy, strcmp, etc, but not others like printf. Is this because strcpy and strcmp have been compiled with llvm and printf has not? Regards, Ryan -- Ryan M. Lefever [217.333.7231] [http://www.ews.uiuc.edu/~lefever]