[cfe-dev] [LLVMdev] Handling SRet on Windows x86

[Timur Iskhodzhanov]

[+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!