search for: analyzeformalargu

...terface, which leads to a number of backends creating their own CCState subclass: * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also a SpeciallCallingConv field. Provides its own implementation of AnalyzeFormalArguments etc that fill these vectors. * HexagonCCState: adds a single extra field - NumNamedVarArgParams. * PPCCCState: adds an OriginalArgWasPPCF128 bool vector. Arguably reduces boilerplate vs MipsCCState by just having PPCISelLowering call PPCCCState::PreAnalyzeCallOperands directly. * SystemZCCStat...

...) } define void @bar(i32 %a, i32 %b) { call @llvm.myVM.call_native(i32 2, i32 %a, i32 %b) } ... But here I am unsure how to handle the return type of this intrinsic (can it be overloaded to accept any return type?) and whether I can reuse the TargetLowering::LowerCall and CCState::AnalyzeFormalArguments stuff. Maybe another option is to add some kind of metadata to these function declarations and then check in "LowerCall" whether these metadata flags are present. If so, then extract the funcIdx from metadata and lower this call in a special way. If this is doable, are there some...

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which only pushed the pointer to the stack. However, I don't want to push the pointer to the stack but COPY the pointee. Indeed, I want to keep the pointer where it is BUT re-poin...

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>> which only pushed the pointer to the stack. Really, all it did was ask LowerCall and LowerFormalArguments to pass the pointer on the stack (well, strictly "ByVal") as...

...er of > backends creating their own CCState subclass: > > * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, > OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also > a SpeciallCallingConv field. Provides its own implementation of > AnalyzeFormalArguments etc that fill these vectors. CallOperandIsFixed was needed because the CCIf* classes could tell whether the argument list was variable or not, but couldn't tell whether a particular argument was part of the variable portion of the argument list. At the time, it struck me as odd that this...

...b) { > call @llvm.myVM.call_native(i32 2, i32 %a, i32 %b) > } > ... > But here I am unsure how to handle the return type of this intrinsic > (can > it be overloaded to accept any return type?) and whether I can reuse > the > TargetLowering::LowerCall and CCState::AnalyzeFormalArguments stuff. > > > > Maybe another option is to add some kind of metadata to these function > declarations and then check in "LowerCall" whether these metadata flags > are present. If so, then extract the funcIdx from metadata and lower > this > call in a special...

...ber of > backends creating their own CCState subclass: > > * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, > OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also > a SpeciallCallingConv field. Provides its own implementation of > AnalyzeFormalArguments etc that fill these vectors. > * HexagonCCState: adds a single extra field - NumNamedVarArgParams. > * PPCCCState: adds an OriginalArgWasPPCF128 bool vector. Arguably reduces > boilerplate vs MipsCCState by just having PPCISelLowering call > PPCCCState::PreAnalyzeCallOperands direc...

...nks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >> a SpeciallCallingConv field. Provides its own implementation of >> AnalyzeFormalArguments etc that fill these vectors. > > CallOperandIsFixed was needed because the CCIf* classes could tell whether the argument list was variable or not, but couldn't tell whether a particular argument was part of the variable portion of the argument list. At the time, it struck me as odd t...

...aniel, much appreciated. > >>> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >>> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >>> a SpeciallCallingConv field. Provides its own implementation of >>> AnalyzeFormalArguments etc that fill these vectors. >> >> CallOperandIsFixed was needed because the CCIf* classes could tell whether the argument list was variable or not, but couldn't tell whether a particular argument was part of the variable portion of the argument list. At the time, it struck me...

Hello, I want to find information/documentation on how reorganize stack frame (add other information, etc.) & how add new calling convention into ARM backend? I think it is needed to modify lowering of CALL, RET & FORMAL_ARGUMENT instruction, and also to modify emitPrologue & emitEpilogue functions. What are the others things to modify in order to realize my

Hi Robert, > I tried adding to the XCoreCallingConv.td: > CCIfByVal<CCPassByVal<0,4>> // pushes pointer to the stack This looks sensible to me. After that it comes down to cooperation between XCoreISelLowering's LowerFormalArguments and LowerCall functions. LowerFormalArguments is at the beginning of a function and is responsible for taking arguments out of

...CCState subclass: >> >> * MipsCCState: adds bool vectors OriginalArgWasF128, >> OriginalArgWasFloat, >> OriginalArgWasFloatVector, OriginalRetWasFloatVector, >> CallOperandIsFixed. Also >> a SpeciallCallingConv field. Provides its own implementation of >> AnalyzeFormalArguments etc that fill these vectors. >> * HexagonCCState: adds a single extra field - NumNamedVarArgParams. >> * PPCCCState: adds an OriginalArgWasPPCF128 bool vector. Arguably >> reduces >> boilerplate vs MipsCCState by just having PPCISelLowering call >> PPCCCState::Pr...

...byval aggregate on the callee's frame Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>> which only pushed the pointer to the stack. Really, all it did was ask LowerCall and LowerFormalArguments to pass the pointer on the stack (well, strictly "ByVal") as...

Hi - help! I have read through previous threads on the subject of 'byval' e.g. https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code

...tRegInfo(); assert(!isVarArg && "VarArg not supported"); // Assign locations to all of the incoming arguments. SmallVector<CCValAssign, 16> ArgLocs; CCState CCInfo(CallConv, isVarArg, DAG.getMachineFunction(), ArgLocs, *DAG.getContext()); CCInfo.AnalyzeFormalArguments(Ins, CC_FOO); for (auto &VA : ArgLocs) { if (VA.isRegLoc()) { // Arguments passed in registers EVT RegVT = VA.getLocVT(); const unsigned VReg = RegInfo.createVirtualRegister(&FOO::PRegsRegClass); RegInfo.addLiveIn(VA.getLocReg(), VReg); SDValue ArgI...