search for: ccpromotetotyp

...rrayidx, 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 are returned in register...

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 IselLowering, it still failed to...

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

...nario 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 i...

...y 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 CCCu...

...l 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: >&gt...

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

...---------------------------- 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]>>, -------------------------------...

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

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

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

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

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

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

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

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

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

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,

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

Hello. My target architecture supports natively 16 bit integers (i16). Whenever I write in C programs using only short types, clang compiles the program to LLVM and converts the i16 data to i32 to perform arithmetic operations and then truncates the results to i16. Then, the InstructionCombining (INSTCOMBINE or IC) pass removes these conversions back and forth from i16, except for