search for: armcallingconv

On Aug 6, 2012, at 6:58 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > See ARMCallingConv.td:113. The alignment of the arg is checked and if > it's 8-byte aligned, the proper registers are chosen. Are you sure? In this case, it looks like the frontend is translating the argument type to [2 x i32], so it's not going to have 8-byte alignment. This looks like a bug to me (but...

>> See ARMCallingConv.td:113. The alignment of the arg is checked and if >> it's 8-byte aligned, the proper registers are chosen. > > Are you sure? In this case, it looks like the frontend is translating the argument type to [2 x i32], so it's not going to have 8-byte alignment. This looks like a b...

...lvm DAG > generator? We do not have any fixed registers for argument passing. > Everything including the formal and actual arguments will take part in > a global interprocedural regalloc. You don't have to formally specify calling convention. For example, ARM backend does not have a ARMCallingConv.td file, all the argument passing info are implicitly defined in the lowering code. To start, you should specify legal register files, legal operations, etc. See XXXISelLowering.cpp for examples. Evan > > > Any pointers to learn about this will be a great help. > Sanjiv > ____...

Could anybody guide me what information do I need to know about my target in order to provide the target lowering info to the llvm DAG generator? We do not have any fixed registers for argument passing. Everything including the formal and actual arguments will take part in a global interprocedural regalloc. Any pointers to learn about this will be a great help. Sanjiv

...GHC/ARM calling convention code missing from it. So I've grabbed LLVM HEAD and applied the GHC/ARM calling convention patch to it with some tweaks to resolve rejects. I've also changed a patch a little bit to use LLVM's facility to generate callee-saved regs list automatically from ARMCallingConv.td. However either I don't know well syntax for callee save regs specification or the tool does not support empty list, I've needed to use simple work around to come to the same result as was in the previous patch version. (For those interested, the error with empty list was "expec...

...668ad54c922297f59/llvm/lib/CodeGen/CodeGenPrepare.cpp#L6751 5 - https://github.com/llvm/llvm-project/blob/d0307f93a7658e6d0eef1ffd0b0ed4f1506bfc13/llvm/include/llvm/Analysis/VectorUtils.h#L278 6 - https://github.com/llvm/llvm-project/blob/fafec5155e39f5dad098376c1beb4a56604aa655/llvm/lib/Target/ARM/ARMCallingConv.cpp#L207 7 - https://github.com/llvm/llvm-project/blob/d0307f93a7658e6d0eef1ffd0b0ed4f1506bfc13/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp#L563 8 - https://github.com/llvm/llvm-project/blob/7eeb82b58554163962d2696ce9be7d021d5b25d4/llvm/include/llvm/CodeGen/MachineConstantPool.h#L76 9 -...

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

...? We do not have any fixed registers for argument passing. > > Everything including the formal and actual arguments will take part in > > a global interprocedural regalloc. > > You don't have to formally specify calling convention. For example, > ARM backend does not have a ARMCallingConv.td file, all the argument > passing info are implicitly defined in the lowering code. > > To start, you should specify legal register files, legal operations, > etc. See XXXISelLowering.cpp for examples. > > Evan > > > > > > > Any pointers to learn about this...

See ARMCallingConv.td:113. The alignment of the arg is checked and if it's 8-byte aligned, the proper registers are chosen. deep On Tue, Aug 7, 2012 at 1:20 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Yes, I see the load is 8-byte aligned in the bit code. > > My question was, assuming tha...

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

...;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)) { &g...

...n't using the CCState machinery? >> >> Please clarify. I am not sure what you mean by CCState machinery. > > The ARM Target doesn't use the class CCState. For example, > CCState.AnalyzeCallOperands, CCState.AnalyzeCallReturn, > CCState.AnalyzeReturn, etc. There is no ARMCallingConv.td as there is > for other targets. All calling convention decisions are made manually. > > If there is no reason not to, it might simplify adding the AAPCS > Standard Variants like AAPCS-AFP, etc. since they'll be defined with > TableGen and therefore more readily extended. >...

...nstead of real hardware regs. > I don't know much how tablegen would work in this case, but I'd expect > it to break during codegen (with a horrid error message) if you try to > compile that to an ARMv4-ish core. I'm not sure I understand you right here, but if you look into ARMCallingConv.td file, you will see that exactly the same statements are used in FastCC_ARM_APCS so I think if it's going to be broken, then the GHC calling convention is not the only culprit here. Or are you talking about actual compilation for the target platform? Anyway, I think majority of GHC/ARM re...

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

...vm/lib/CodeGen/CodeGenPrepare.cpp#L6751 > 5 - > https://github.com/llvm/llvm-project/blob/d0307f93a7658e6d0eef1ffd0b0ed4f1506bfc13/llvm/include/llvm/Analysis/VectorUtils.h#L278 > 6 - > https://github.com/llvm/llvm-project/blob/fafec5155e39f5dad098376c1beb4a56604aa655/llvm/lib/Target/ARM/ARMCallingConv.cpp#L207 > 7 - > https://github.com/llvm/llvm-project/blob/d0307f93a7658e6d0eef1ffd0b0ed4f1506bfc13/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp#L563 > 8 - > https://github.com/llvm/llvm-project/blob/7eeb82b58554163962d2696ce9be7d021d5b25d4/llvm/include/llvm/CodeGen/MachineCo...

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

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

Yes, I see the load is 8-byte aligned in the bit code. My question was, assuming that arguments requiring double word alignment have to be passed in even/odd registers, how does the backend know that %0 has to be passed in register r2 and r3? *tail call arm_aapcscc void (i32, ...)* @foo0(i32 1, [2 x i32] %0) nounwindt * It doesn't seem that ARM backend can figure out that "[2 x i32]

...ve 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 }; >&...

...t;>> >>>> 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 }; >>>>> + &g...