similar to: [LLVMdev] CallInst API Changes Ready

Reminder... Round one has been committed as <http://llvm.org/viewvc/llvm-project?view=rev&revision=107432> I hope that it got digested by now, as I plan to commit the second round tomorrow. In fact I made two test commits already: r107480 and r107580, the former of which actually uncovered some more uses of the low-level interfaces in core LLVM that have slipped through. To be

Sounds great to me Gabor. I really like your new incremental approach to this patch set. -Chris On Jun 30, 2010, at 1:59 PM, Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks >

On Wednesday 11 July 2007 18:55, David Greene wrote: > I ask because I'm ready to commit the CallInst interface changes and it > will break llvm-gcc. There is no way to preserve the interfaces llvm-gcc > needs because there are three places in the llvm-gcc code where > the old interface conflicts with the new one (passing two Value*'s vs. > passing two iterators to a

On Jul 11, 2007, at 4:55 PM, David Greene wrote: > On Wednesday 11 July 2007 17:03, Devang Patel wrote: >> Hi All, >> >> llvm-gcc-4-2 development branch is now open for development at >> >> llvm.org/svn/llvm-project/llvm-gcc-4-2 >> >> It is not yet ready, it can not even bootstrap. I welcome LLVM >> developers to test and apply fixes! > >

On Mon, 16 Jul 2007, David Greene wrote: >> I can send an llvm-gcc patch for someone to apply, or if the current >> llvm-gcc is going to be put under subversion soon I can wait for that and >> commit the changes myself. Either way, we will want the CallInst and >> llvm-gcc changes to happen as close together in time as possible to >> minimize the chance of disrupting

On Wednesday 11 July 2007 17:03, Devang Patel wrote: > Hi All, > > llvm-gcc-4-2 development branch is now open for development at > > llvm.org/svn/llvm-project/llvm-gcc-4-2 > > It is not yet ready, it can not even bootstrap. I welcome LLVM > developers to test and apply fixes! How does this relate to the current llvm-gcc? Is that version still going to be added to the

Gabor Greif wrote: > Am 30.06.2010 um 23:31 schrieb John Criswell: > > >> Stupid question: is making the getOperand() method of CallInst >> going to work? For example, if I have the following code: >> >> void >> method (Instruction * I) { >> I->getOperand(2); >> ... >> } >> >> void method2 (CallInst * CI) {

Gabor Greif wrote: > Hi all, > > I am almost ready for the last step with landing my long-standing patch. > I have converted (almost) all low-level interface users of CallInst to > respective high-level interfaces. What remains is a handful of hunks > to flip the switch. > > But before I do the final commit I'd like to coerce all external users > to code against the

Am 30.06.2010 um 23:31 schrieb John Criswell: > > Stupid question: is making the getOperand() method of CallInst > going to work? For example, if I have the following code: > > void > method (Instruction * I) { > I->getOperand(2); > ... > } > > void method2 (CallInst * CI) { > method (CI); > ... > } > > Will method() still work

Hi all, I am almost ready for the last step with landing my long-standing patch. I have converted (almost) all low-level interface users of CallInst to respective high-level interfaces. What remains is a handful of hunks to flip the switch. But before I do the final commit I'd like to coerce all external users to code against the high-level interface too. This will (almost, but see below)

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

On Apr 24, 2008, at 9:03 AM, Gabor Greif wrote: > > As you can see, the use-diet changes actually lower the build time > of kimwitu++! (this is as of yesterday's r50182). > Parity is not only reached, but surpassed. Thanks for these numbers. Do you know how much of this increase is due to co-allocating Use arrays with their users, and how much is due to the actual shrinking of

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

Howdy. Due to a rather unique hosting setup, I need to relocate the dispatch.fcgifile to a directory outside of /path/to/application/public. The setup looks like: /path/to/content/RailsApp/ -- all application files /path/to/fcgi-bin/RailsApp/ -- dispatch.fcgi I''ve modified dispatch.fcgi to find environment.rb; however, all requests for static files (index.html, javascripts, etc) fail

Hi, I have the following piece of code: %34 = fptosi float %33 to i32 %35 = call i32 @function(i32 %34) nounwind I would like of know how can I duplicate the statement %35 ? , as follows: %34 = fptosi float %33 to i32 %35 = call i32 @function(i32 %34) nounwind *%36 = **call i32 @function(i32 %34) nounwind* * * i.e, two instructions exactly equal. Using clone, results in badref. Moreover, how

What is the difference between a CallInst and an InvokeInst in LLVM? Is an InvokeInst a CallInst that can throw an exception? Thanks, Ryan

Hello All, I'm developing timing analysis tool using LLVM. After several analysis phases, I want to instantiate several instructions in the basic block. Instructions that I try to instantiate are like below; call void (int)* %waitABC(int 10) %tmp = call int (int, int*)* %doABC(int %i, int* %total) I think I should use 'CallInst' class in 'Instructions.h' file. How I could

I implement the following function,which gets CallInst * and should perform the following: 1. Change the value of the argument if condition1 takes place 2. Change the type of the argument if condition2 takes place 3. Add addition argument/s if condition3 takes place void argChange(CallInst * I) { for (unsigned index = 0; index < I->getNumOperands(); ++index) {

You are probably calling setName() on the called Function, which in-turned renamed the called Function instead of replacing the called function. Depending on your use-case, if you are certain that you only need to modify CallInsts, then you could simply call CallInst::setCalledFunction , otherwise it’s probably wiser to use CallSite as a wrapper for both CallInst and InvokeInst. Do note, however,

Hi, Inserting a call instruction is a bit of a pain. The only way I know how to do it is to write a bunch of code like the following: std::vector<const Type*> formalArgs; formalArgs.push_back(arg1->getType()); formalArgs.push_back(arg2->getType()); ... formalArgs.push_back(argn->getType()); std::vector<Value*> args; args.push_back(arg1);