After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote:> I'm not currently setup to be able to run the A/B comparison tests > that test-suite relies upon. > > Fhourstones-3.1 looks to be the simplest. If you can send me the two > .o files from either EABI or Darwin, I can dig into why this went > wrong for you. > > deep > > On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote: >> Sorry I haven't gotten back to you earlier. I have been busy. >> >> I ran some MultiSource/Benchmark earlier today. Looks like there are >> some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, MiBench/ >> consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and >> sim. Are you able to test them on your end? >> >> Evan >> >> On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote: >> >>> This time with the test cases actually attached. >>> >>> deep >>> >>> On Tue, Feb 17, 2009 at 4:41 PM, Sandeep Patel <deeppatel1987 at gmail.com >>> > wrote: >>>> On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> >>>> wrote: >>>>> /// Information about how the value is assigned. >>>>> - LocInfo HTP : 7; >>>>> + LocInfo HTP : 6; >>>>> >>>>> Do you know why this change is needed? Are we running out of bits? >>>> >>>> HTP was't using all of these bits. I needed the hasCustom bit to come >>>> from somewhere unless we wanted to grow this struct, so I grabbed a >>>> bit from HTP. >>>> >>>>> - NeededStackSize = 4; >>>>> - break; >>>>> - case MVT::i64: >>>>> - case MVT::f64: >>>>> - if (firstGPR < 3) >>>>> - NeededGPRs = 2; >>>>> - else if (firstGPR == 3) { >>>>> - NeededGPRs = 1; >>>>> - NeededStackSize = 4; >>>>> - } else >>>>> - NeededStackSize = 8; >>>>> + State.addLoc(CCValAssign::getCustomMem(ValNo, ValVT, >>>>> + >>>>> State.AllocateStack(4, 4), >>>>> + MVT::i32, LocInfo)); >>>>> + return true; // we handled it >>>>> >>>>> Your change isn't handling the "NeededStackSize = 8" case. >>>> >>>> I believe it is. I've attached two additional test cases. The >>>> difference is that this case isn't handled by the CCCustomFns. They >>>> fail to allocate any regs and then handling falls through to an >>>> CCAssignToStack in ARMCallingConv.td. This is how other targets >>>> handle >>>> similar allocations. >>>> >>>>> ++ static const unsigned HiRegList[] = { ARM::R0, ARM::R2 }; >>>>> + static const unsigned LoRegList[] = { ARM::R1, ARM::R3 }; >>>>> + >>>>> + if (unsigned Reg = State.AllocateReg(HiRegList, LoRegList, 2)) { >>>>> + unsigned i; >>>>> + for (i = 0; i < 2; ++i) >>>>> + if (HiRegList[i] == Reg) >>>>> + break; >>>>> + >>>>> + State.addLoc(CCValAssign::getCustomReg(ValNo, ValVT, Reg, >>>>> + MVT::i32, LocInfo)); >>>>> + State.addLoc(CCValAssign::getCustomReg(ValNo, ValVT, >>>>> LoRegList[i], >>>>> + MVT::i32, LocInfo)); >>>>> >>>>> Since 'i' is used after the loop, please choose a better variable >>>>> name. >>>>> >>>>> Actually, is the loop necessary? We know the low register is always >>>>> one after the high register. Perhaps you can use >>>>> ARMRegisterInfo::getRegisterNumbering(Reg), add one to 1. And the >>>>> lookup the register enum with a new function (something like >>>>> getRegFromRegisterNum(RegNo, ValVT)). >>>>> >>>>> The patch is looking good. I need to run it through some more tests. >>>>> Unfortunately ARM target is a bit broken right now. I hope to fix it >>>>> today. >>>> >>>> I'll submit a revised patch after we've settled on the >>>> NeededStackSize=8 issue. >>>> >>>> deep >>>> >>>>> Thanks, >>>>> >>>>> Evan >>>>> >>>>> On Feb 13, 2009, at 8:27 PM, Sandeep Patel wrote: >>>>> >>>>>> Sorry left a small bit of cruft in ARMCallingConv.td. A corrected >>>>>> patch it attached. >>>>>> >>>>>> deep >>>>>> >>>>>> On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com >>>>>>> wrote: >>>>>>> Sure. Updated patches attached. >>>>>>> >>>>>>> deep >>>>>>> >>>>>>> On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: >>>>>>>> >>>>>>>>> ARMTargetLowering doesn't need case #1, but it seemed like you >>>>>>>>> and Dan >>>>>>>>> wanted a more generic way to inject C++ code into the process >>>>>>>>> so I >>>>>>>>> tried to make the mechanism a bit more general. >>>>>>>> >>>>>>>> Ok. Since ARM doesn't need it and it's the only client, I'd much >>>>>>>> rather have CCCustomFn just return a single bool indicating >>>>>>>> whether it >>>>>>>> can handle the arg. Would that be ok? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Evan >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> deep >>>>>>>>> >>>>>>>>> On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: >>>>>>>>>> >>>>>>>>>>> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Although it's not generally needed for ARM's use of >>>>>>>>>>>>> CCCustom, I >>>>>>>>>>>>> return >>>>>>>>>>>>> two bools to handle the four possible outcomes to keep the >>>>>>>>>>>>> mechanism >>>>>>>>>>>>> flexible: >>>>>>>>>>>>> >>>>>>>>>>>>> * if CCCustomFn handled the arg or not >>>>>>>>>>>>> * if CCCustomFn wants to end processing of the arg or not >>>>>>>>>>>> >>>>>>>>>>>> +/// CCCustomFn - This function assigns a location for Val, >>>>>>>>>>>> possibly >>>>>>>>>>>> updating >>>>>>>>>>>> +/// all args to reflect changes and indicates if it handled >>>>>>>>>>>> it. It >>>>>>>>>>>> must set >>>>>>>>>>>> +/// isCustom if it handles the arg and returns true. >>>>>>>>>>>> +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, >>>>>>>>>>>> + MVT &LocVT, CCValAssign::LocInfo >>>>>>>>>>>> &LocInfo, >>>>>>>>>>>> + ISD::ArgFlagsTy &ArgFlags, CCState >>>>>>>>>>>> &State, >>>>>>>>>>>> + bool &result); >>>>>>>>>>>> >>>>>>>>>>>> Is "result" what you refer to as "isCustom" in the comments? >>>>>>>>>>>> >>>>>>>>>>>> Sorry, I am still confused. You mean it could return true but >>>>>>>>>>>> set >>>>>>>>>>>> 'result' to false? That means it has handled the argument >>>>>>>>>>>> but it >>>>>>>>>>>> would >>>>>>>>>>>> not process any more arguments? What scenario do you envision >>>>>>>>>>>> that >>>>>>>>>>>> this will be useful? I'd rather keep it simple. >>>>>>>>>>> >>>>>>>>>>> As you note there are three actual legitimate cases (of the >>>>>>>>>>> four >>>>>>>>>>> combos): >>>>>>>>>>> >>>>>>>>>>> 1. The CCCustomFn wants the arg handling to proceed. This >>>>>>>>>>> might >>>>>>>>>>> be >>>>>>>>>>> used akin to CCPromoteToType. >>>>>>>>>>> 2. The CCCustomFn entirely handled the arg. This might be used >>>>>>>>>>> akin to >>>>>>>>>>> CCAssignToReg. >>>>>>>>>>> 3. The CCCustomFn tried to handle the arg, but failed. >>>>>>>>>>> >>>>>>>>>>> these results are conveyed the following ways: >>>>>>>>>>> >>>>>>>>>>> 1. The CCCustomFn returns false, &result is not used. >>>>>>>>>>> 2. The CCCustomFn returns true, &result is false; >>>>>>>>>>> 3. The CCCustomFn returns true, &result is true. >>>>>>>>>> >>>>>>>>>> I don't think we want to support #1. If the target want to add >>>>>>>>>> custom >>>>>>>>>> code to handle an argument, if should be responsible for >>>>>>>>>> outputting >>>>>>>>>> legal code. Is there an actual need to support #1? >>>>>>>>>> >>>>>>>>>> Evan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I tried to keep these CCCustomFns looking like TableGen >>>>>>>>>>> generated >>>>>>>>>>> code. Suggestions of how to reorganize these results are >>>>>>>>>>> welcome. :-) >>>>>>>>>>> Perhaps better comments around the typedef for CCCustomFn >>>>>>>>>>> would >>>>>>>>>>> suffice? >>>>>>>>>>> >>>>>>>>>>> The isCustom flag is simply a means for this machinery to >>>>>>>>>>> convey to >>>>>>>>>>> the TargetLowering functions to process this arg specially. It >>>>>>>>>>> may >>>>>>>>>>> not >>>>>>>>>>> always be possible for the TargetLowering functions to >>>>>>>>>>> determine >>>>>>>>>>> that >>>>>>>>>>> the arg needs special handling after all the changes made by >>>>>>>>>>> the >>>>>>>>>>> CCCustomFn or CCPromoteToType and other transformations. >>>>>>>>>>> >>>>>>>>>>>>> I placed the "unsigned i" outside those loops because i is >>>>>>>>>>>>> used >>>>>>>>>>>>> after >>>>>>>>>>>>> the loop. If there's a better index search pattern, I'd be >>>>>>>>>>>>> happy >>>>>>>>>>>>> to >>>>>>>>>>>>> change it. >>>>>>>>>>>> >>>>>>>>>>>> Ok. >>>>>>>>>>>> >>>>>>>>>>>> One more nitpick: >>>>>>>>>>>> >>>>>>>>>>>> +/// CCCustom - calls a custom arg handling function >>>>>>>>>>>> >>>>>>>>>>>> Please capitalize "calls" and end with a period. >>>>>>>>>>> >>>>>>>>>>> Once we settle on the result handling changes, I'll submit an >>>>>>>>>>> update >>>>>>>>>>> with this change. >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Evan >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Attached is an updated patch against HEAD that has DebugLoc >>>>>>>>>>>>> changes. I >>>>>>>>>>>>> also split out the ARMAsmPrinter fix into it's own patch. >>>>>>>>>>>>> >>>>>>>>>>>>> deep >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Feb 9, 2009 at 8:54 AM, Evan Cheng >>>>>>>>>>>>> <echeng at apple.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Thanks Sandeep. I did a quick scan, this looks really good. >>>>>>>>>>>>>> But I >>>>>>>>>>>>>> do >>>>>>>>>>>>>> have a question: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +/// CCCustomFn - This function assigns a location for Val, >>>>>>>>>>>>>> possibly >>>>>>>>>>>>>> updating >>>>>>>>>>>>>> +/// all args to reflect changes and indicates if it >>>>>>>>>>>>>> handled >>>>>>>>>>>>>> it. It >>>>>>>>>>>>>> must set >>>>>>>>>>>>>> +/// isCustom if it handles the arg and returns true. >>>>>>>>>>>>>> +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, >>>>>>>>>>>>>> + MVT &LocVT, CCValAssign::LocInfo >>>>>>>>>>>>>> &LocInfo, >>>>>>>>>>>>>> + ISD::ArgFlagsTy &ArgFlags, CCState >>>>>>>>>>>>>> &State, >>>>>>>>>>>>>> + bool &result); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it necessary to return two bools (the second is >>>>>>>>>>>>>> returned by >>>>>>>>>>>>>> reference in 'result')? I am confused about the semantics >>>>>>>>>>>>>> of >>>>>>>>>>>>>> 'result'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, a nitpick: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + unsigned i; >>>>>>>>>>>>>> + for (i = 0; i < 4; ++i) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The convention we use is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + for (unsigned i = 0; i < 4; ++i) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Evan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 6, 2009, at 6:02 PM, Sandeep Patel wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think I've got all the cases handled now, implementing >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> CCCustom<"foo"> callbacks into C++. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This also fixes a crash when returning i128. I've also >>>>>>>>>>>>>>> included a >>>>>>>>>>>>>>> small asm constraint fix that was needed to build newlib. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> deep >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Jan 19, 2009 at 10:18 AM, Evan Cheng >>>>>>>>>>>>>>> <evan.cheng at apple.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> One problem with this approach is that since i64 isn't >>>>>>>>>>>>>>>>>> legal, >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> bitcast would require custom C++ code in the ARM >>>>>>>>>>>>>>>>>> target to >>>>>>>>>>>>>>>>>> handle properly. It might make sense to introduce >>>>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> CCIfType<[f64], CCCustom> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> where CCCustom is a new entity that tells the calling >>>>>>>>>>>>>>>>>> convention >>>>>>>>>>>>>>>>>> code to to let the target do something not easily >>>>>>>>>>>>>>>>>> representable >>>>>>>>>>>>>>>>>> in the tablegen minilanguage. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am thinking that this requires two changes: add a >>>>>>>>>>>>>>>>> flag to >>>>>>>>>>>>>>>>> CCValAssign (take a bit from HTP) to indicate isCustom >>>>>>>>>>>>>>>>> and a >>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> author an arbitrary CCAction by including the source >>>>>>>>>>>>>>>>> directly in >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> TableGen mini-language. This latter change might want a >>>>>>>>>>>>>>>>> generic >>>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>> to the TableGen language. For example, the syntax >>>>>>>>>>>>>>>>> might be >>>>>>>>>>>>>>>>> like: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> class foo : CCCustomAction { >>>>>>>>>>>>>>>>> code <<< EOF >>>>>>>>>>>>>>>>> ....multi-line C++ code goes here that allocates regs >>>>>>>>>>>>>>>>> & mem >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> sets CCValAssign::isCustom.... >>>>>>>>>>>>>>>>> EOF >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does this seem reasonable? An alternative is for >>>>>>>>>>>>>>>>> CCCustom >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> take a >>>>>>>>>>>>>>>>> string that names a function to be called: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> CCIfType<[f64], CCCustom<"MyCustomLoweringFunc">> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the function signature for such functions will have to >>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>> results: if the CC processing is finished and if it the >>>>>>>>>>>>>>>>> func >>>>>>>>>>>>>>>>> succeeded >>>>>>>>>>>>>>>>> or failed: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I like the second solution better. It seems rather >>>>>>>>>>>>>>>> cumbersome >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> embed >>>>>>>>>>>>>>>> multi-line c++ code in td files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Evan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, >>>>>>>>>>>>>>>>> MVT LocVT, CCValAssign::LocInfo >>>>>>>>>>>>>>>>> LocInfo, >>>>>>>>>>>>>>>>> ISD::ArgFlagsTy ArgFlags, CCState >>>>>>>>>>>>>>>>> &State, >>>>>>>>>>>>>>>>> bool &result); >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> arm_callingconv >>>>>>>>>>>>>>> .diff>_______________________________________________ >>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>> >>>>>>>>>>>>> < >>>>>>>>>>>>> arm_callingconv >>>>>>>>>>>>> .diff >>>>>>>>>>>>>> < >>>>>>>>>>>>>> arm_fixes >>>>>>>>>>>>>> .diff>_______________________________________________ >>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> LLVM Developers mailing list >>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> LLVM Developers mailing list >>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> LLVM Developers mailing list >>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>> >>>>>>> >>>>>> < >>>>>> arm_callingconv >>>>>> .diff >>>>>> ><arm_fixes.diff>_______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>> >>>> >>> < >>> arm_stack64_tests.diff>_______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >-------------- next part -------------- A non-text attachment was scrubbed... Name: arm_callingconv.patch Type: application/octet-stream Size: 56486 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090416/e47fc14f/attachment.obj>
Xerxes Rånby
2009-Apr-16 19:44 UTC
[LLVMdev] Using CallingConvLower in ARM target (ARM i64 lowering fixed by applying patch from pr 3898 )
Den 2009-04-16 13:37, Xerxes Rånby skrev:> Some failing tests have now gotten better error reporting than before: > > $ llvm-as< test/CodeGen/Generic/select-cc.ll | llc > Formal argument #0 has unhandled type i64 > Stack dump: > 0. Program arguments: llc > 1. Running pass 'ARM Instruction Selection' on function '@vector_select' > Aborted > > $ llvm-as< test/CodeGen/X86/dagcombine-buildvector.ll | llc > Formal argument #1 has unhandled type i64 > Stack dump: > 0. Program arguments: llc > 1. Running pass 'ARM Instruction Selection' on function '@test' > Aborted >These two test succeeds after applying the attached patch from pr 3898 http://llvm.org/bugs/show_bug.cgi?id=3898 [xranby at pusspuss llvm]$ llvm-as < test/CodeGen/Generic/select-cc.ll | llc -march=arm .file "<stdin>" .text .globl vector_select .align 2 vector_select: stmfd sp!, {r4, r5, r6, r7, lr} mov r4, r3 mov r5, r2 mov r6, r1 mov r7, r0 mov r2, #0 mov r3, #0 bl __gedf2 ldr r2, [sp, #+32] cmp r0, #0 mov r3, r4 movge r3, r2 ldr r1, [sp, #+28] cmp r0, #0 mov r2, r5 movge r2, r1 ldr r12, [sp, #+24] cmp r0, #0 mov r1, r6 movge r1, r12 ldr r12, [sp, #+20] cmp r0, #0 mov r0, r7 movge r0, r12 ldmfd sp!, {r4, r5, r6, r7, pc} .size vector_select, .-vector_select [xranby at pusspuss llvm]$ llvm-as < test/CodeGen/X86/dagcombine-buildvector.ll | llc -march=arm .file "<stdin>" .text .globl test .align 2 test: ldr r1, [sp, #+12] str r1, [r0, #+12] ldr r1, [sp, #+8] str r1, [r0, #+8] stmia r0, {r2, r3} bx lr .size test, .-test [xranby at pusspuss llvm]$ Thanks Jakob! Cheers, and have a great day! Xerxes
Done! Sandeep, this is really a great change. I had seen the discussion of it but hadn't looked at the details until now. Thanks a lot for contributing this. While I was reviewing it, I found some a few small nit-picky things to clean up (mostly in comments and whitespace). Sorry -- I'm a bit compulsive that way! I will commit those changes in a few minutes. Other than those very minor things, your change looks great. On Apr 16, 2009, at 5:08 PM, Evan Cheng wrote:> > On Apr 16, 2009, at 2:52 AM, Sandeep Patel wrote: > >> After wasting an inordinate amount of time trying to get test-suite >> to >> run on arm-apple-darwin so I could reproduce your results, attached >> is >> a patch that fixes the small copy&paste error of having 8-byte >> alignment for stack-allocated f64s instead of the proper 4-byte. I've >> updated the patch to the top of trunk changes as well. > > Thanks for doing the hard work! Can you document your journey > somewhere? :-) > > Bob, can you review Deep's patch and commit it for him? > > Thanks, > > Evan > >> >> deep >> >> On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel <deeppatel1987 at gmail.com >> > wrote: >>> I'm not currently setup to be able to run the A/B comparison tests >>> that test-suite relies upon. >>> >>> Fhourstones-3.1 looks to be the simplest. If you can send me the two >>> .o files from either EABI or Darwin, I can dig into why this went >>> wrong for you. >>> >>> deep >>> >>> On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> >>> wrote: >>>> Sorry I haven't gotten back to you earlier. I have been busy. >>>> >>>> I ran some MultiSource/Benchmark earlier today. Looks like there >>>> are >>>> some failures: Fhourstones-3.1, Fhourstones, McCat/08-main, >>>> MiBench/ >>>> consumer-lame, Olden/Power, Olden/voronoi, mafft/pairlocalign, and >>>> sim. Are you able to test them on your end? >>>> >>>> Evan >>>> >>>> On Feb 17, 2009, at 4:42 PM, Sandeep Patel wrote: >>>> >>>>> This time with the test cases actually attached. >>>>> >>>>> deep >>>>> >>>>> On Tue, Feb 17, 2009 at 4:41 PM, Sandeep Patel <deeppatel1987 at gmail.com >>>>>> wrote: >>>>>> On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com >>>>>> > >>>>>> wrote: >>>>>>> /// Information about how the value is assigned. >>>>>>> - LocInfo HTP : 7; >>>>>>> + LocInfo HTP : 6; >>>>>>> >>>>>>> Do you know why this change is needed? Are we running out of >>>>>>> bits? >>>>>> >>>>>> HTP was't using all of these bits. I needed the hasCustom bit >>>>>> to come >>>>>> from somewhere unless we wanted to grow this struct, so I >>>>>> grabbed a >>>>>> bit from HTP. >>>>>> >>>>>>> - NeededStackSize = 4; >>>>>>> - break; >>>>>>> - case MVT::i64: >>>>>>> - case MVT::f64: >>>>>>> - if (firstGPR < 3) >>>>>>> - NeededGPRs = 2; >>>>>>> - else if (firstGPR == 3) { >>>>>>> - NeededGPRs = 1; >>>>>>> - NeededStackSize = 4; >>>>>>> - } else >>>>>>> - NeededStackSize = 8; >>>>>>> + State.addLoc(CCValAssign::getCustomMem(ValNo, ValVT, >>>>>>> + >>>>>>> State.AllocateStack(4, 4), >>>>>>> + MVT::i32, >>>>>>> LocInfo)); >>>>>>> + return true; // we handled it >>>>>>> >>>>>>> Your change isn't handling the "NeededStackSize = 8" case. >>>>>> >>>>>> I believe it is. I've attached two additional test cases. The >>>>>> difference is that this case isn't handled by the CCCustomFns. >>>>>> They >>>>>> fail to allocate any regs and then handling falls through to an >>>>>> CCAssignToStack in ARMCallingConv.td. This is how other targets >>>>>> handle >>>>>> similar allocations. >>>>>> >>>>>>> ++ static const unsigned HiRegList[] = { ARM::R0, ARM::R2 }; >>>>>>> + static const unsigned LoRegList[] = { ARM::R1, ARM::R3 }; >>>>>>> + >>>>>>> + if (unsigned Reg = State.AllocateReg(HiRegList, LoRegList, >>>>>>> 2)) { >>>>>>> + unsigned i; >>>>>>> + for (i = 0; i < 2; ++i) >>>>>>> + if (HiRegList[i] == Reg) >>>>>>> + break; >>>>>>> + >>>>>>> + State.addLoc(CCValAssign::getCustomReg(ValNo, ValVT, Reg, >>>>>>> + MVT::i32, LocInfo)); >>>>>>> + State.addLoc(CCValAssign::getCustomReg(ValNo, ValVT, >>>>>>> LoRegList[i], >>>>>>> + MVT::i32, LocInfo)); >>>>>>> >>>>>>> Since 'i' is used after the loop, please choose a better >>>>>>> variable >>>>>>> name. >>>>>>> >>>>>>> Actually, is the loop necessary? We know the low register is >>>>>>> always >>>>>>> one after the high register. Perhaps you can use >>>>>>> ARMRegisterInfo::getRegisterNumbering(Reg), add one to 1. And >>>>>>> the >>>>>>> lookup the register enum with a new function (something like >>>>>>> getRegFromRegisterNum(RegNo, ValVT)). >>>>>>> >>>>>>> The patch is looking good. I need to run it through some more >>>>>>> tests. >>>>>>> Unfortunately ARM target is a bit broken right now. I hope to >>>>>>> fix it >>>>>>> today. >>>>>> >>>>>> I'll submit a revised patch after we've settled on the >>>>>> NeededStackSize=8 issue. >>>>>> >>>>>> deep >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Evan >>>>>>> >>>>>>> On Feb 13, 2009, at 8:27 PM, Sandeep Patel wrote: >>>>>>> >>>>>>>> Sorry left a small bit of cruft in ARMCallingConv.td. A >>>>>>>> corrected >>>>>>>> patch it attached. >>>>>>>> >>>>>>>> deep >>>>>>>> >>>>>>>> On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com >>>>>>>>> wrote: >>>>>>>>> Sure. Updated patches attached. >>>>>>>>> >>>>>>>>> deep >>>>>>>>> >>>>>>>>> On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: >>>>>>>>>> >>>>>>>>>>> ARMTargetLowering doesn't need case #1, but it seemed like >>>>>>>>>>> you >>>>>>>>>>> and Dan >>>>>>>>>>> wanted a more generic way to inject C++ code into the >>>>>>>>>>> process >>>>>>>>>>> so I >>>>>>>>>>> tried to make the mechanism a bit more general. >>>>>>>>>> >>>>>>>>>> Ok. Since ARM doesn't need it and it's the only client, I'd >>>>>>>>>> much >>>>>>>>>> rather have CCCustomFn just return a single bool indicating >>>>>>>>>> whether it >>>>>>>>>> can handle the arg. Would that be ok? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Evan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> deep >>>>>>>>>>> >>>>>>>>>>> On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com >>>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Although it's not generally needed for ARM's use of >>>>>>>>>>>>>>> CCCustom, I >>>>>>>>>>>>>>> return >>>>>>>>>>>>>>> two bools to handle the four possible outcomes to keep >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> mechanism >>>>>>>>>>>>>>> flexible: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * if CCCustomFn handled the arg or not >>>>>>>>>>>>>>> * if CCCustomFn wants to end processing of the arg or >>>>>>>>>>>>>>> not >>>>>>>>>>>>>> >>>>>>>>>>>>>> +/// CCCustomFn - This function assigns a location for >>>>>>>>>>>>>> Val, >>>>>>>>>>>>>> possibly >>>>>>>>>>>>>> updating >>>>>>>>>>>>>> +/// all args to reflect changes and indicates if it >>>>>>>>>>>>>> handled >>>>>>>>>>>>>> it. It >>>>>>>>>>>>>> must set >>>>>>>>>>>>>> +/// isCustom if it handles the arg and returns true. >>>>>>>>>>>>>> +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, >>>>>>>>>>>>>> + MVT &LocVT, CCValAssign::LocInfo >>>>>>>>>>>>>> &LocInfo, >>>>>>>>>>>>>> + ISD::ArgFlagsTy &ArgFlags, >>>>>>>>>>>>>> CCState >>>>>>>>>>>>>> &State, >>>>>>>>>>>>>> + bool &result); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is "result" what you refer to as "isCustom" in the >>>>>>>>>>>>>> comments? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry, I am still confused. You mean it could return >>>>>>>>>>>>>> true but >>>>>>>>>>>>>> set >>>>>>>>>>>>>> 'result' to false? That means it has handled the argument >>>>>>>>>>>>>> but it >>>>>>>>>>>>>> would >>>>>>>>>>>>>> not process any more arguments? What scenario do you >>>>>>>>>>>>>> envision >>>>>>>>>>>>>> that >>>>>>>>>>>>>> this will be useful? I'd rather keep it simple. >>>>>>>>>>>>> >>>>>>>>>>>>> As you note there are three actual legitimate cases (of >>>>>>>>>>>>> the >>>>>>>>>>>>> four >>>>>>>>>>>>> combos): >>>>>>>>>>>>> >>>>>>>>>>>>> 1. The CCCustomFn wants the arg handling to proceed. This >>>>>>>>>>>>> might >>>>>>>>>>>>> be >>>>>>>>>>>>> used akin to CCPromoteToType. >>>>>>>>>>>>> 2. The CCCustomFn entirely handled the arg. This might >>>>>>>>>>>>> be used >>>>>>>>>>>>> akin to >>>>>>>>>>>>> CCAssignToReg. >>>>>>>>>>>>> 3. The CCCustomFn tried to handle the arg, but failed. >>>>>>>>>>>>> >>>>>>>>>>>>> these results are conveyed the following ways: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. The CCCustomFn returns false, &result is not used. >>>>>>>>>>>>> 2. The CCCustomFn returns true, &result is false; >>>>>>>>>>>>> 3. The CCCustomFn returns true, &result is true. >>>>>>>>>>>> >>>>>>>>>>>> I don't think we want to support #1. If the target want >>>>>>>>>>>> to add >>>>>>>>>>>> custom >>>>>>>>>>>> code to handle an argument, if should be responsible for >>>>>>>>>>>> outputting >>>>>>>>>>>> legal code. Is there an actual need to support #1? >>>>>>>>>>>> >>>>>>>>>>>> Evan >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to keep these CCCustomFns looking like TableGen >>>>>>>>>>>>> generated >>>>>>>>>>>>> code. Suggestions of how to reorganize these results are >>>>>>>>>>>>> welcome. :-) >>>>>>>>>>>>> Perhaps better comments around the typedef for CCCustomFn >>>>>>>>>>>>> would >>>>>>>>>>>>> suffice? >>>>>>>>>>>>> >>>>>>>>>>>>> The isCustom flag is simply a means for this machinery to >>>>>>>>>>>>> convey to >>>>>>>>>>>>> the TargetLowering functions to process this arg >>>>>>>>>>>>> specially. It >>>>>>>>>>>>> may >>>>>>>>>>>>> not >>>>>>>>>>>>> always be possible for the TargetLowering functions to >>>>>>>>>>>>> determine >>>>>>>>>>>>> that >>>>>>>>>>>>> the arg needs special handling after all the changes >>>>>>>>>>>>> made by >>>>>>>>>>>>> the >>>>>>>>>>>>> CCCustomFn or CCPromoteToType and other transformations. >>>>>>>>>>>>> >>>>>>>>>>>>>>> I placed the "unsigned i" outside those loops because >>>>>>>>>>>>>>> i is >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>> after >>>>>>>>>>>>>>> the loop. If there's a better index search pattern, >>>>>>>>>>>>>>> I'd be >>>>>>>>>>>>>>> happy >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> change it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One more nitpick: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +/// CCCustom - calls a custom arg handling function >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please capitalize "calls" and end with a period. >>>>>>>>>>>>> >>>>>>>>>>>>> Once we settle on the result handling changes, I'll >>>>>>>>>>>>> submit an >>>>>>>>>>>>> update >>>>>>>>>>>>> with this change. >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Evan >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Attached is an updated patch against HEAD that has >>>>>>>>>>>>>>> DebugLoc >>>>>>>>>>>>>>> changes. I >>>>>>>>>>>>>>> also split out the ARMAsmPrinter fix into it's own >>>>>>>>>>>>>>> patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> deep >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Feb 9, 2009 at 8:54 AM, Evan Cheng >>>>>>>>>>>>>>> <echeng at apple.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Thanks Sandeep. I did a quick scan, this looks really >>>>>>>>>>>>>>>> good. >>>>>>>>>>>>>>>> But I >>>>>>>>>>>>>>>> do >>>>>>>>>>>>>>>> have a question: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +/// CCCustomFn - This function assigns a location >>>>>>>>>>>>>>>> for Val, >>>>>>>>>>>>>>>> possibly >>>>>>>>>>>>>>>> updating >>>>>>>>>>>>>>>> +/// all args to reflect changes and indicates if it >>>>>>>>>>>>>>>> handled >>>>>>>>>>>>>>>> it. It >>>>>>>>>>>>>>>> must set >>>>>>>>>>>>>>>> +/// isCustom if it handles the arg and returns true. >>>>>>>>>>>>>>>> +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, >>>>>>>>>>>>>>>> + MVT &LocVT, >>>>>>>>>>>>>>>> CCValAssign::LocInfo >>>>>>>>>>>>>>>> &LocInfo, >>>>>>>>>>>>>>>> + ISD::ArgFlagsTy &ArgFlags, >>>>>>>>>>>>>>>> CCState >>>>>>>>>>>>>>>> &State, >>>>>>>>>>>>>>>> + bool &result); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is it necessary to return two bools (the second is >>>>>>>>>>>>>>>> returned by >>>>>>>>>>>>>>>> reference in 'result')? I am confused about the >>>>>>>>>>>>>>>> semantics >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> 'result'. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, a nitpick: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + unsigned i; >>>>>>>>>>>>>>>> + for (i = 0; i < 4; ++i) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The convention we use is: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + for (unsigned i = 0; i < 4; ++i) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Evan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Feb 6, 2009, at 6:02 PM, Sandeep Patel wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think I've got all the cases handled now, >>>>>>>>>>>>>>>>> implementing >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> CCCustom<"foo"> callbacks into C++. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This also fixes a crash when returning i128. I've also >>>>>>>>>>>>>>>>> included a >>>>>>>>>>>>>>>>> small asm constraint fix that was needed to build >>>>>>>>>>>>>>>>> newlib. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> deep >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 19, 2009 at 10:18 AM, Evan Cheng >>>>>>>>>>>>>>>>> <evan.cheng at apple.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> One problem with this approach is that since i64 >>>>>>>>>>>>>>>>>>>> isn't >>>>>>>>>>>>>>>>>>>> legal, >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> bitcast would require custom C++ code in the ARM >>>>>>>>>>>>>>>>>>>> target to >>>>>>>>>>>>>>>>>>>> handle properly. It might make sense to introduce >>>>>>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> CCIfType<[f64], CCCustom> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> where CCCustom is a new entity that tells the >>>>>>>>>>>>>>>>>>>> calling >>>>>>>>>>>>>>>>>>>> convention >>>>>>>>>>>>>>>>>>>> code to to let the target do something not easily >>>>>>>>>>>>>>>>>>>> representable >>>>>>>>>>>>>>>>>>>> in the tablegen minilanguage. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am thinking that this requires two changes: add a >>>>>>>>>>>>>>>>>>> flag to >>>>>>>>>>>>>>>>>>> CCValAssign (take a bit from HTP) to indicate >>>>>>>>>>>>>>>>>>> isCustom >>>>>>>>>>>>>>>>>>> and a >>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> author an arbitrary CCAction by including the source >>>>>>>>>>>>>>>>>>> directly in >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> TableGen mini-language. This latter change might >>>>>>>>>>>>>>>>>>> want a >>>>>>>>>>>>>>>>>>> generic >>>>>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>>>> to the TableGen language. For example, the syntax >>>>>>>>>>>>>>>>>>> might be >>>>>>>>>>>>>>>>>>> like: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> class foo : CCCustomAction { >>>>>>>>>>>>>>>>>>> code <<< EOF >>>>>>>>>>>>>>>>>>> ....multi-line C++ code goes here that allocates >>>>>>>>>>>>>>>>>>> regs >>>>>>>>>>>>>>>>>>> & mem >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> sets CCValAssign::isCustom.... >>>>>>>>>>>>>>>>>>> EOF >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Does this seem reasonable? An alternative is for >>>>>>>>>>>>>>>>>>> CCCustom >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> take a >>>>>>>>>>>>>>>>>>> string that names a function to be called: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> CCIfType<[f64], CCCustom<"MyCustomLoweringFunc">> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> the function signature for such functions will >>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>>>> results: if the CC processing is finished and if >>>>>>>>>>>>>>>>>>> it the >>>>>>>>>>>>>>>>>>> func >>>>>>>>>>>>>>>>>>> succeeded >>>>>>>>>>>>>>>>>>> or failed: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I like the second solution better. It seems rather >>>>>>>>>>>>>>>>>> cumbersome >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> embed >>>>>>>>>>>>>>>>>> multi-line c++ code in td files. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Evan >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, >>>>>>>>>>>>>>>>>>> MVT LocVT, CCValAssign::LocInfo >>>>>>>>>>>>>>>>>>> LocInfo, >>>>>>>>>>>>>>>>>>> ISD::ArgFlagsTy ArgFlags, CCState >>>>>>>>>>>>>>>>>>> &State, >>>>>>>>>>>>>>>>>>> bool &result); >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>> arm_callingconv >>>>>>>>>>>>>>>>> .diff>_______________________________________________ >>>>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> arm_callingconv >>>>>>>>>>>>>>> .diff >>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>> arm_fixes >>>>>>>>>>>>>>>> .diff>_______________________________________________ >>>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> LLVM Developers mailing list >>>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> LLVM Developers mailing list >>>>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>>>>> >>>>>>>>> >>>>>>>> < >>>>>>>> arm_callingconv >>>>>>>> .diff >>>>>>>>> < >>>>>>>>> arm_fixes.diff>_______________________________________________ >>>>>>>> LLVM Developers mailing list >>>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> LLVM Developers mailing list >>>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>>>>> >>>>>> >>>>> < >>>>> arm_stack64_tests >>>>> .diff>_______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>> >> < >> arm_callingconv.patch>_______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >