On Thu, Feb 16, 2012 at 7:38 PM, Aaron Ballman <[email protected]> wrote:
> On Thu, Feb 16, 2012 at 8:52 PM, Eli Friedman <[email protected]> wrote:
>> On Thu, Feb 16, 2012 at 6:25 PM, Aaron Ballman <[email protected]>
>> wrote:
>>> Here's the next attempt at the MSVC thiscall support patch, this time
>>> with test cases and an improved tablegen declaration.
>>>
>>> This is the first time I've done a test case for clang or llvm
>>> codegen, so please pay special attention to the test cases and let me
>>> know if I'm off-base (and what I should do differently).
>>
>> You might want to make the LLVM testcase a bit stronger by using CHECK-NEXT.
>
> Does CHECK-NEXT basically chain the checks together to check several
> lines as a group?
Basically, yes.
>> + if (callingConvention == llvm::CallingConv::X86_ThisCall &&
>> + Context.getLangOptions().MicrosoftMode && RT->isStructureType()) {
>> + return false;
>> + }
>>
>> You shouldn't make the behavior of thiscall depend on MicrosoftMode;
>> checking that the calling convention is thiscall should be sufficient.
>> (If someone explicitly requests thiscall outside of MicrosoftMode,
>> they expect a Microsoft-compatible calling convention.)
>
> I didn't want to break compatibility if people were already using
> thiscall (for instance, for MinGW compiles).
>
> Takumi, I believe you know far more about MinGW than I do -- do you
> think this change would break anything if I were to make it the
> default for thiscall instead of MicrosoftMode only?
Note that MicrosoftMode isn't the right way to check for mingw anyway;
take a look at how IsWin32FloatStructABI works.
-Eli
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
