similar to: [LLVMdev] RFC: Tail call optimization X86

On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: > >> We can set a policy of treating fastcc external functions >> as c functions. Then there is no chance of introducing ABI >> incompatibility. > this means limiting tail call opt to protected/invisible functions > within a module? > a little limiting i think. It makes sense to be extra careful at this point.

Yes please. Evan On Oct 5, 2007, at 11:55 AM, Arnold Schwaighofer wrote: > > On 5 Oct 2007, at 20:47, Evan Cheng wrote: > >> >> On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: >> >>> >>>> We can set a policy of treating fastcc external functions >>>> as c functions. Then there is no chance of introducing ABI >>>>

Ok. Like I said, I am not too concerned with one or two llcbeta failures. That's expected. Thx, Evan On Oct 5, 2007, at 3:18 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com > wrote: > Another round ;) Sadly not beer. > > tested against r42630 darwin-x86: > SPASS llc-beta still fails > > thanks for the patience > > On 5 Oct 2007, at 20:58, Evan

On 5 Oct 2007, at 19:41, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> Hi Evan, >> I incoporated the changes you request but to the following i have got >> a question: >> >>> Also, moving the option >>> there will allow us to change fastcc ABI (callee popping arguments) >>> only when this option is on.

On 5 Oct 2007, at 20:47, Evan Cheng wrote: > > On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: > >> >>> We can set a policy of treating fastcc external functions >>> as c functions. Then there is no chance of introducing ABI >>> incompatibility. >> this means limiting tail call opt to protected/invisible functions >> within a module?

On Oct 9, 2007, at 4:29 AM, Arnold Schwaighofer wrote: > There have been some changes in X86RegisterInfo.cpp that make my last > patch not merge. Sorry, I know it's a moving target. :-) > > Also there was an error in my code concerning how inreg parameters > were lowered. > > the latest version of the patch does not fail the SPASS llc-beta test > anymore

The patch is in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061548.html . Okay to commit :) On Thu, Apr 24, 2008 at 7:35 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com> wrote: > Another round :) > > I'll post the patch to llvm-commits cause i guess people might get > annoyed by my series of patches :). > > On Tue, Apr 22, 2008 at

On Sep 11, 2007, at 11:21 AM, Arnold Schwaighofer wrote: > Begin forwarded message: > >> From: Evan Cheng <evan.cheng at apple.com> >> Date: 11 September 2007 19:26:39 GMT+02:00 >> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Subject: Re: [LLVMdev] RFC: Tail call optimization X86 >> Reply-To: LLVM Developers Mailing List <llvmdev

On Fri, 5 Oct 2007, Arnold Schwaighofer wrote: >> to me like llvm-gcc honors that. Certainly it should. > > This would imply one fastcc abi (callee pops args on return) to rule > them all? > That is only if fastcall translates to llvm fastcc of course. fastcall != fastcc. fastcall is a well defined convention on x86 that has very specific ABI requirements. fastcc, on the

On Oct 4, 2007, at 2:31 PM, Arnold Schwaighofer wrote: > > On 4 Oct 2007, at 00:22, Evan Cheng wrote: >>> ifeq ($(ARCH),x86) >>> LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call- >>> opt- >>> align-stack >> Please remove -regalloc=local -fast. We want to test this patch >> separately. > > just did a test with >

Okay I finished testing (TEST=nightly report): Results with my optimization not enabled in test-suite look great: darwin-x86 (r42159): *passed llvm/test (except for arm failures and one x86 failure that where also in the vanilla version) *same number of failures for vanilla version and my patch version in test-suite gentoo/x86 in a parallels virtual machine (really sloooow, that was an

> > ifeq ($(ARCH),x86) > > LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call-opt- > > align-stack okay i ll do another round of testing with LLCBETAOPTION := -tail-call-opt -tail-call-opt-align-stack > Please remove -regalloc=local -fast. We want to test this patch > separately. Can you explain the advantages / disadvantages of -tail- >

On 4 Oct 2007, at 00:22, Evan Cheng wrote: >> ifeq ($(ARCH),x86) >> LLCBETAOPTION := -regalloc=local -fast -tail-call-opt -tail-call-opt- >> align-stack > Please remove -regalloc=local -fast. We want to test this patch > separately. just did a test with LLCBETAOPTION := -tail-call-opt -tail-call-opt-align-stack this time only SPASS llc-beta fails (comparing with vanilla

Begin forwarded message: > From: Evan Cheng <evan.cheng at apple.com> > Date: 11 September 2007 19:26:39 GMT+02:00 > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Tail call optimization X86 > Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > Hi Arnold, > > Thanks for the patch. Some questions

There have been some changes in X86RegisterInfo.cpp that make my last patch not merge. Also there was an error in my code concerning how inreg parameters were lowered. the latest version of the patch does not fail the SPASS llc-beta test anymore (darwin-x86). if/when someone has the time to look at it - i would be happy to mail it. i think i should no longer clobber the mailing list with

On 2007-10-05, at 13:56, Arnold Schwaighofer wrote: > On 5 Oct 2007, at 19:41, Evan Cheng wrote: > >> In theory, any function can be marked fastcc. But llvm-gcc c / c++ >> frontend does *not* mark any external functions fastcc. Also, the >> optimizer only changes the calling convention of internal >> functions to fastcc. > > well i hope llvm-gcc won't

> Ok, I don't expect everything would just work. But please run at least > SingleSource and MultiSource and let us know what breaks. Once it's > proven to pass a good chunk of the tests it can be checked in but > turned off. This will allow us to test it as llcbeta. > I just ran the test suite in llvm-test with a vanilla copy of the svn tree on darwin-x86. To perform the

On Oct 2, 2007, at 2:27 AM, Arnold Schwaighofer wrote: > Hi all, > > I changed the code that checks whether a tail call is really > eligible for optimization so that it performs the check/fix in > SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also > eliminated an error that caused the remaining failing test cases in > the test-suite. > > The

Another round :) I'll post the patch to llvm-commits cause i guess people might get annoyed by my series of patches :). On Tue, Apr 22, 2008 at 10:34 PM, Evan Cheng <evan.cheng at apple.com> wrote: . >> +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, >> ... > That's fine. Please break it into two parts and move the target > independent part

Another round ;) Sadly not beer. tested against r42630 darwin-x86: SPASS llc-beta still fails thanks for the patience On 5 Oct 2007, at 20:58, Evan Cheng wrote: > Yes please. >> okay then i'll make tailcallopt switch stack adjusting behaviour? the patch for the test suite (when/if it's needed) would be something like: >>>>> --- Makefile.programs (revision