search for: ccassigntoreg

...alues promote i8 & i16 to i32 : def RetCC_test : CallingConv<[ // Promote i8 returns to i32. CCIfType<[i8], CCPromoteToType<i32>>, // Promote i16 returns to i32. CCIfType<[i16], CCPromoteToType<i32>>, // i32 are returned in register R0 CCIfType<[i32], CCAssignToReg<[R0L]>> ]>; I've now changed this to : def RetCC_test : CallingConv<[ // i8 are returned in register R0 CCIfType<[i8], CCAssignToReg<[R0B]>>, // i16 are returned in register R0 CCIfType<[i16], CCAssignToReg<[R0W]>>, // i32 are returned in regis...

Hi Karel, I understand this patch has already been merged (to 3.0), so don't take my question as stopping the merge to head, I'm just making sure I got it right... The rest looks correct. + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, + CCIfType<[f64], CCAssignToReg<[D8, D9, D10, D11]>>, + CCIfType<[f32], CCAssignToReg<[S16, S17, S18, S19, S20, S21, S22, S23]>>, Does this mean that for floating point support in GHC, you need VFP registers? I don't know much how tablegen would...

Hello, first of all: one of the LLVM 3.0 new feature was a support for GHC specific calling convention on ARM platform. It looks like this support was merged just into 3.0 branch, specifically it appeared in 3.0 RC2. Anyway, I hope this is just a mistake or omission that such support was merged only into 3.0 and not also into HEAD. I've just found it by testing LLVM 3.1 with GHC 7.4.2 and

...tate which gets told about each argument as it passes by and allows CCCustom functions to access its special information (or, possibly, a CCIf with a cast). CCCustom<"TellCCStateAboutArg">, [...] CCIf<"cast<MyCCState>(State).isPointerArg()">, CCAssignToReg<[P1, P2]>>, Putting that information in the InputArg/OutputArg and incorporating it the CCAssignFn interface allows a more straightforward implementation in the targets, in my view (for both our uses). It's also information that's readily available when InputArg/OutputArgs are...

...======================================= --- lib/Target/X86/X86CallingConv.td (revision 164763) +++ lib/Target/X86/X86CallingConv.td (working copy) @@ -335,7 +335,8 @@ CCIfType<[i8, i16], CCPromoteToType<i32>>, // Pass sret arguments indirectly through EAX - CCIfSRet<CCAssignToReg<[EAX]>>, + CCIfSRet<CCAssignToStack<4, 4>>, // The first integer argument is passed in ECX CCIfType<[i32], CCAssignToReg<[ECX]>>, --------------------------------- [hope this doesn't get wrapped in your email client] Unfortunately, this patch also chan...

Hi, all On the website, it says, CCAssignToRegWithShadow <registerList, shadowList> — similar to CCAssignToReg, but with a shadow list of registers I don't know when we should use CCAssignToRegWithShadow. Because I am not a architecture expert, please bear with my naive question. Take ARMCallingConv.td as an example, CCIfType&lt...

...For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType<[f64], CCBitConvertToType<i64>>, CCIfType<[i64], CCExtractElements<2, i32>>, CCIfType<[i32], CCAssignToReg<[R0, R1]>> ]>; The problem is that i64 handling requires splitting into 2 x i32 registers. I am not sure how to build CCExtractElements as shown. The current organization of CCState::AnalyzeReturn does not allow for reissuing of the RET with an altered set of operands which is the solu...

..., On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9, D10, D11]>>, > + CCIfType<[f32], CCAssignToReg<[S16, S17, S18, S19, S20, S21, S22, S23]>>, > > Does this mean that for floating point support in GHC, you need VFP registers? Yes and no. Shortly: o...

...so it should already be handled. > > > def RetCC_ARM_APCS : CallingConv<[ > CCIfType<[f32], CCBitConvertToType<i32>>, > CCIfType<[f64], CCBitConvertToType<i64>>, > CCIfType<[i64], CCExtractElements<2, i32>>, > > CCIfType<[i32], CCAssignToReg<[R0, R1]>> > ]>; > > The problem is that i64 handling requires splitting into 2 x i32 > registers. I am not sure how to build CCExtractElements as shown. The > current organization of CCState::AnalyzeReturn does not allow for > reissuing of the RET with an altered set...

Hi Tim, > So I've come to the conclusion that the real flaw is LLVM > not exposing enough information to the target-dependent > backend code for it to do the right thing. We also had this problem. You might find this patch useful as a starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html /Patrik Hägglund -----Original Message----- From: llvmdev-bounces

...-===// //===----------------------------------------------------------------------===// // DLX Return Value Calling Convention //===----------------------------------------------------------------------===// def RetCC_DLX : CallingConv<[ // i32 is returned in register R1 CCIfType<[i32], CCAssignToReg<[R1]>> ]>; //===----------------------------------------------------------------------===// // DLX Argument Calling Conventions //===----------------------------------------------------------------------===// def CC_DLX : CallingConv<[ // The first 6 arguments are passed in regist...

Hi, (Forward from cfe-commits, where some backend stuff has come up). This is an issue I've been thinking about quite a bit recently, and I agree that the biggest problem is the one below: > * The big thing still missing here is that there is no logic to check how many VFP registers have already been used for other arguments. When deciding whether to pass an argument as a homogeneous

...interface allows a more straightforward implementation in the > targets, in my view (for both our uses). It's also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > > CCIf<"SourceTy->isPointerTy()", CCAssignToReg<[P1, P2]>>; > > I've got a patch which implements it for ARM and X86 (though not HFAs using > the features yet, I'm still musing on the best interface to present there > -- "HFA* byval" for target simplicity or "HFA" for user simplicity), I'll &...

Hello >  I don't know when we should use CCAssignToRegWithShadow. Because > I am not a architecture expert, please bear with my naive question. > Take ARMCallingConv.td as an example, ARM is not good example :) Look into win64 calling convention. Shadow means if some register is allocated for incoming argument another one cannot be used for argum...

...gt; 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 tried to keep these CCCust...

I'm currently working on the MSP430 backend and I have some problems implementing the calling convention. It's a 16-bit architecture which dictates that arguments should be passed in registers R15-R12. Therefore, I have something like this is a .td file: CCIfType<[i16], CCAssignToReg<[R15W, R14W, R13W, R12W]>> 32-bit arguments should be passed in R14:R15 (R12:R13). Since it's a little endian architecture, R14 (R12) should contain the least significant bytes and R15 (R13) the most significant ones. The problem is that before the calling convention is applied, i3...

...gt; 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 ret...

...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 tr...

On 20/02/2008, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Feb 2008, Raja Mukherji wrote: > > Hi all, > > I was wondering what the best way of adding a custom calling convention in llvm? > > It is quite easy to add custom calling conventions. Check out how the > various x86 fastcall, stdcall, etc things are handled. Am I correct in thinking that it's

...our >>>> 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, &amp...