similar to: [LLVMdev] [HEADSUP] Another attempt at CallInst operand rotation

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 >

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

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) {

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

Hello; I am trying to clone some call instructions in the IR and then set the call destination of those call instructions to my own library functions that happens to have the same arguments and return types of the original callee. It works perfectly for direct calls using setCalledFunction(). But when the function call is indirect, is there a way to set the callee? Something like

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

Dear all, To explain my problem I am attaching a demonstration package "myclasspkg": I have the following two S4 classes with similar inheritance: SubSubClassA <- SubClassB <- BaseClass SubSubClassB <- SubClassB <- BaseClass In R I am calling the following functions: > library(myclasspkg) > subA <-

On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote: > Hello Dale, > > this is an updated version of the tail call optimization patch for > powerpc. could you have a look at it? > > i added code to support ppc64 (untested, will try to get access to > ppc64 on a friend's machine). > incorporated evan's formatting suggestions. ;) > > will run another round

On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> wrote: > More nitpicks: > ... > No need for else here. :-) Done > SPDiff = (int)CallerMinReservedArea - (int)ParamSize; > > Just change last statement to > int SPDiff = (int)... Done > > +bool > +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, > +

I have a single table that two people enter data into. Person A creates the record and I need to specify certain required fields in his form. Person B has a separate form and she fills in additional fields and I need to specify that some of these are required. Since the data is all in one table and since the validations are in the model, won''t Rails complain when person A tries to

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Everyone, Want to let you know that I''ll be syncing over all the aspects of RoR''s mailing lists and it''s site onto a new dedicated server that''ll just be for RubyOnRails.org/.com. It''ll all be seemless and kept in sync until David flips the DNS switch, but there will be a couple of times where the

On 17/03/20 7:50 pm, Aki Tuomi wrote: > Dovecot is now a nearly 20 year old product, and during that time it has accumulated many different features and plugins in its core repository. > > We are starting to gradually remove some of these parts, which are unused, untested or deprecated. > We will provide advance notification before removing anything. > > To start, the following

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 18/03/2020 00:06 Rupert Gallagher <ruga@protonmail.com> wrote: </div> <div> <br> </div> <div> <br>

Was there any reason for this message to be HTML-only? On Wed, Mar 18, 2020 at 07:13:12AM +0200, Aki Tuomi wrote: > <!doctype html> > <html> > <head> > <meta charset="UTF-8"> > </head> > <body> > <div> > <br> > </div> > <blockquote type="cite"> > <div> >

On Wed, 18 Mar 2020 09:51:51 -0400, Hendrik Boom stated: >Was there any reason for this message to be HTML-only? Was there any reason to 'top post' and include the HTML text? -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL:

On Wed, Mar 18, 2020 at 10:38:37AM -0400, Jerry wrote: > On Wed, 18 Mar 2020 09:51:51 -0400, Hendrik Boom stated: > >Was there any reason for this message to be HTML-only? > > Was there any reason to 'top post' and include the HTML text? Yes. (1) To indicate that my question was about the whole message and not its contents. I normally don't top-post. (2) To make it

> On 18/03/2020 17:31 Hendrik Boom <hendrik at topoi.pooq.com> wrote: > > > On Wed, Mar 18, 2020 at 10:38:37AM -0400, Jerry wrote: > > On Wed, 18 Mar 2020 09:51:51 -0400, Hendrik Boom stated: > > >Was there any reason for this message to be HTML-only? > > > > Was there any reason to 'top post' and include the HTML text? > > Yes. >

18.03.20, 04:32 CET, Peter: > Please consider holding off on removing features for the next major > release, 2.4.0 instead. It makes sense to retain, in as much as is > possible, feature backwards compatibility across a major release. Seconded! That you are going to drop features from the code base that are old and rarely used is understandable. Doing so in a minor release is not.

I fully agree with this: > Please consider holding off on removing features for the next major > release, 2.4.0 instead. It makes sense to retain, in as much as is > possible, feature backwards compatibility across a major release.