search for: cciftyp

...e i8 %call, i8* %arrayidx, align 1 ret void } declare signext i8 @cnv(i8*) Now originally (at the time I hadn't added 8/16 bit register support) I had made the calling convention return values 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...

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. 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....

...RM target. Lowering CALL nodes will come later. > > This patch does not handle f64 and i64 types. For these types, it > would be ideal to request the conversions below: i64 isn't Legal on ARM, 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 spl...

...AssignToRegWithShadow <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<[i32], CCIfAlign<"8", CCAssignToRegWithShadow<[R0, R2], [R0, R1]>>> If we assign a value to R0(R2), then what happen to R0(R1)? def RetCC_ARM_AAPCS_Common : CallingConv<[ CCIfType<[i32], CCAssignToReg<[R0, R1, R2, R3]>>, CCIfType<[i64], CCAssig...

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

...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) t...

...r is allocated for incoming argument another one cannot be used for argument allocation. On Win64 general purpose registers shadow xmm and vice versa, so, say, if you put argument into ecx, the xmm0 is marked as already occupied, if you put argument into xmm1, edx is marked as occupied, etc. > CCIfType<[i32], CCIfAlign<"8", CCAssignToRegWithShadow<[R0, R2], [R0, R1]>>> > >  If we assign a value to R0(R2), then what happen to R0(R1)? It will be marked as occupied. > def RetCC_ARM_AAPCS_Common : CallingConv<[ >  CCIfType<[i32], CCAssignToReg<[R0, R...

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

...hman <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 > CCVal...

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

...issue on Windows: --------------------------------- Index: lib/Target/X86/X86CallingConv.td =================================================================== --- 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]>>, -...

Dear there, I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. My initial thought is: (1) I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. but looks it is not the case. (2) Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLo...

...; >>>> 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 thi...

...ne 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. >>>> >>>&gt...

...--------------------===// //===----------------------------------------------------------------------===// // 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 argum...

Hi Is there a way to enforce a different alignment on vales on stack as compared to other basic types. Particularly, i would like characters to be stored at 2 byte boundary. thanks dz

...2 byte boundary. > Check out examples in the lib/Target/* directories. For instance in X86CallingConv.td, we have things like this: def CC_X86_64_C : CallingConv<[ ... // __m64 vectors get 8-byte stack slots that are 8-byte aligned. CCIfType<[x86mmx,v1i64], CCAssignToStack<8, 8>> } The second parameter to CCAssigneToStack is the alignment for that type. -bw

...aracters to be stored at 2 byte boundary. >> > Check out examples in the lib/Target/* directories. For instance in X86CallingConv.td, we have things like this: > > def CC_X86_64_C : CallingConv<[ > ... >  // __m64 vectors get 8-byte stack slots that are 8-byte aligned. >  CCIfType<[x86mmx,v1i64], CCAssignToStack<8, 8>> > } > > The second parameter to CCAssigneToStack is the alignment for that type. > > -bw > >

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

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