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. The policy can be changed when we enable tail call optimization by default.> > but i think if it is documented that there will be a incompatibility > between > modules compiled with tailcallopt on/off that is okay? > and this would only happen if someone other than llvm-gcc used llvm > as a backend > anyway.Documentation isn't going to be enough. We will do everything possible to ensure there isn't abi incompatibility. But at this point, it's important the patch does not impact codegen in any way when tail call optimization is off. This allows us to get a true sense of the performance impact. Evan> > so i will make tailcallopt toggle the stack adjusting behaviour. with > llvm-gcc this won't be a problem > and if someone other using llvm as a backend runs in to a problem > than there is the documentation > and the maillist that will help. > > is that okay? > > regards arnold > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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? >> a little limiting i think. > > It makes sense to be extra careful at this point. The policy can be > changed when we enable tail call optimization by default. >> >> but i think if it is documented that there will be a incompatibility >> between >> modules compiled with tailcallopt on/off that is okay? >> and this would only happen if someone other than llvm-gcc used llvm >> as a backend >> anyway. > > Documentation isn't going to be enough. We will do everything > possible to ensure there isn't abi incompatibility. But at this > point, it's important the patch does not impact codegen in any way > when tail call optimization is off. This allows us to get a true > sense of the performance impact. >okay then i'll make tailcallopt switch stack adjusting behaviour?
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 >>>> 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. The policy can be >> changed when we enable tail call optimization by default. >>> >>> but i think if it is documented that there will be a incompatibility >>> between >>> modules compiled with tailcallopt on/off that is okay? >>> and this would only happen if someone other than llvm-gcc used llvm >>> as a backend >>> anyway. >> >> Documentation isn't going to be enough. We will do everything >> possible to ensure there isn't abi incompatibility. But at this >> point, it's important the patch does not impact codegen in any way >> when tail call optimization is off. This allows us to get a true >> sense of the performance impact. >> > > okay then i'll make tailcallopt switch stack adjusting behaviour? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev