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

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

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

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

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

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

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

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 results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

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

> 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

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

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

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.

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 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. See Chris' email: > > I am not to sure on that. because that would make

On Oct 5, 2007, at 10:41 AM, 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 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 >