[LLVMdev] Handling SRet on Windows x86

David Blaikie dblaikie at gmail.com
Tue Oct 2 09:28:55 PDT 2012


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 output

Just 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



More information about the llvm-dev mailing list