[LLVMdev] Handling SRet on Windows x86
timurrrr at google.com
Tue Oct 2 08:54:35 PDT 2012
[+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
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]
>>> 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?]
> 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!
More information about the llvm-dev