[LLVMdev] Using CallingConvLower in ARM target
Sandeep Patel
deeppatel1987 at gmail.com
Fri Apr 17 16:25:04 PDT 2009
Your edits are more than welcome, of course.
Two spaces after a period? I thought that went out of fashion with typewriters.
deep
On Fri, Apr 17, 2009 at 1:32 PM, Bob Wilson <bob.wilson at apple.com> wrote:
> 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
>>
>
> _______________________________________________
> 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