On Tue, Oct 2, 2012 at 7:03 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote:> Hello Timur, > >> I'd like to ask for advice: >> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >> [I suppose no] > no > >> >> b) Should I be altering CC_X86_32_ThisCall >> OR should I introduce CC_X86_Win32_ThisCall instead? >> [Answer not clear to me - is there any platform besides Windows >> that uses thiscall?] > noCan you please clarify which question you've answered here? Sorry for making the ambiguous questions in the first place :)> It seems for me that you're trying to solve the problem from the wrong > end. As far as I remember, there is a difference - "simple" (probable > POD-like stuff) are returned in the regs, while classes with > non-trivial ctors, etc. are passed / returned on stack.Sort of.> It's frontend responsibility to emit proper IR in this case.Isn't it what's SRet is supposed to be?> See http://llvm.org/bugs/show_bug.cgi?id=5064 and around. This seems > to be the correct description of what's going on.FTR, http://llvm.org/bugs/show_bug.cgi?id=5058 seems to be more up-to-date. Thanks for your reply!
[+cfe-dev as this does seem like both LLVM+Clang issue] [Sorry for an incomplete e-mail context, please see http://llvm.org/PR13676#c6 if you're interested] I've read these bugs and now I'm even more confused than I was before :) What do you think about the following approach: a) I'll create test cases for the major issues I've observed so far These test cases will check both -emit-llvm and llc output They'll have CHECKs for stuff that already works and FIXME+CHECK-NOT for stuff that doesn't. I guess I should put these tests in clang/test/CodeGen[CXX] ? b) As a short-term solution to avoid blocking progress for those who are interested in a functioning Windows compiler I'll publish my patch [which breaks the non-Windows compatibility but improves Windows compat] in PR13676. c) Having these test cases at hand, we can come up with a decent long-term solution Does that sound good to you? On Tue, Oct 2, 2012 at 7:31 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote:> On Tue, Oct 2, 2012 at 7:03 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Hello Timur, >> >>> I'd like to ask for advice: >>> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >>> [I suppose no] >> no >> >>> >>> b) Should I be altering CC_X86_32_ThisCall >>> OR should I introduce CC_X86_Win32_ThisCall instead? >>> [Answer not clear to me - is there any platform besides Windows >>> that uses thiscall?] >> no > Can you please clarify which question you've answered here? > Sorry for making the ambiguous questions in the first place :) > >> It seems for me that you're trying to solve the problem from the wrong >> end. As far as I remember, there is a difference - "simple" (probable >> POD-like stuff) are returned in the regs, while classes with >> non-trivial ctors, etc. are passed / returned on stack. > Sort of. > >> It's frontend responsibility to emit proper IR in this case. > Isn't it what's SRet is supposed to be? > >> See http://llvm.org/bugs/show_bug.cgi?id=5064 and around. This seems >> to be the correct description of what's going on. > FTR, http://llvm.org/bugs/show_bug.cgi?id=5058 seems to be more up-to-date. > > Thanks for your reply!
On Tue, Oct 2, 2012 at 11:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote:> [+cfe-dev as this does seem like both LLVM+Clang issue] > [Sorry for an incomplete e-mail context, please see > http://llvm.org/PR13676#c6 if you're interested] > > I've read these bugs and now I'm even more confused than I was before :) > > What do you think about the following approach: > a) I'll create test cases for the major issues I've observed so far > These test cases will check both -emit-llvm and llc output > They'll have CHECKs for stuff that already works and > FIXME+CHECK-NOT for stuff that doesn't. > I guess I should put these tests in clang/test/CodeGen[CXX] ?Makes sense, assuming we do comparisons against what MSVC 10/11 and gcc emit to determine CHECK vs CHECK-NOT.> b) As a short-term solution to avoid blocking progress for those who > are interested in a functioning Windows compiler I'll publish my patch > [which breaks the non-Windows compatibility but improves Windows > compat] in PR13676.Assuming the patch addresses all of your tests, then that makes sense.> c) Having these test cases at hand, we can come up with a decent > long-term solutionAlso good. Thanks for looking into this! ~Aaron
On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote:> [+cfe-dev as this does seem like both LLVM+Clang issue] > [Sorry for an incomplete e-mail context, please see > http://llvm.org/PR13676#c6 if you're interested] > > I've read these bugs and now I'm even more confused than I was before :) > > What do you think about the following approach: > a) I'll create test cases for the major issues I've observed so far > These test cases will check both -emit-llvm and llc outputJust an aside: generally Clang tests should just verify the emitted LLVM bitcode. If you want to test what machine code/assembly that compiles down to, that should be an LLVM test that starts at LLVM bitcode and goes down to machine code/assembly.> They'll have CHECKs for stuff that already works and > FIXME+CHECK-NOT for stuff that doesn't. > I guess I should put these tests in clang/test/CodeGen[CXX] ? > > b) As a short-term solution to avoid blocking progress for those who > are interested in a functioning Windows compiler I'll publish my patch > [which breaks the non-Windows compatibility but improves Windows > compat] in PR13676. > > c) Having these test cases at hand, we can come up with a decent > long-term solution > > Does that sound good to you? > > On Tue, Oct 2, 2012 at 7:31 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >> On Tue, Oct 2, 2012 at 7:03 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >>> Hello Timur, >>> >>>> I'd like to ask for advice: >>>> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >>>> [I suppose no] >>> no >>> >>>> >>>> b) Should I be altering CC_X86_32_ThisCall >>>> OR should I introduce CC_X86_Win32_ThisCall instead? >>>> [Answer not clear to me - is there any platform besides Windows >>>> that uses thiscall?] >>> no >> Can you please clarify which question you've answered here? >> Sorry for making the ambiguous questions in the first place :) >> >>> It seems for me that you're trying to solve the problem from the wrong >>> end. As far as I remember, there is a difference - "simple" (probable >>> POD-like stuff) are returned in the regs, while classes with >>> non-trivial ctors, etc. are passed / returned on stack. >> Sort of. >> >>> It's frontend responsibility to emit proper IR in this case. >> Isn't it what's SRet is supposed to be? >> >>> See http://llvm.org/bugs/show_bug.cgi?id=5064 and around. This seems >>> to be the correct description of what's going on. >> FTR, http://llvm.org/bugs/show_bug.cgi?id=5058 seems to be more up-to-date. >> >> Thanks for your reply! > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hello Timur,>>> b) Should I be altering CC_X86_32_ThisCall >>> OR should I introduce CC_X86_Win32_ThisCall instead? >>> [Answer not clear to me - is there any platform besides Windows >>> that uses thiscall?] >> no > Can you please clarify which question you've answered here?To both. You're assuming that Windows == MSVC. This is not true.>> It's frontend responsibility to emit proper IR in this case. > Isn't it what's SRet is supposed to be?Yes and no. Yes, when source language / compiler semantics is low-level enough, so it can be represented via single attribute. And no - when there will be additional frontend job to "lift" the stuff. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
> b) As a short-term solution to avoid blocking progress for those who > are interested in a functioning Windows compiler I'll publish my patch > [which breaks the non-Windows compatibility but improves Windows > compat] in PR13676.It does not improve Windows compatibility, because it will break mingw. It will only improve msvc compatibility, though I really doubt that it will cover everything besides trivial cases. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University