search for: outputarg

...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 being constructed. In your case: CCIf<"SourceTy->isPoint...

...there's no indication of where a composite type begins and ends. The latter could be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any source language. The worry is the apparent layering violation by passing a Type* further down. But I'd argue that the TargetLo...

...there's no indication of where a composite type begins and ends. The latter could be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any source language. The worry is the apparent layering violation by passing a Type* further down. But I'd argue that the TargetLo...

LLVM code base seems to be full of base/interface classes, which have methods like virtual SDValue LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const SmallVectorImpl<ISD::InputArg> &Ins, DebugLoc dl, SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const { assert(0 && "N...

On Wednesday 04 Apr 2012 13:27:07 Tim Northover wrote: > 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 being constructed. In your > case: > > CCIf&lt...

...other. This would be a nice general solution instead of something specific to calls. Unrelated, but it would also be nice to make INLINEASM nodes have their own SDNode subclass someday instead of a bunch of magically indexed operands. Similar to Nate's recent shuffle change. InputArg/OutputArg should probably contain an ArgFlagsTy instead of inherit from it. I like the various -'s of random call lowering stuff from the .td files, this is great! -Chris

...; const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 166 9 llc 0x00000001000b72c6 llvm::MBlazeTargetLowering::LowerCall(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, bool&, llvm::SmallVectorImpl<llvm::ISD::OutputArg> const&, llvm::SmallVectorImpl<llvm::SDValue> const&, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 3640 10 llc 0x00000001004fffe8 llvm::TargetLowering::Lo...

...part of ArgFlagsTy but I didn't want to add it there because it appeared to be full and I didn't want to make everyone have a 65-bit ArgFlagsTy just because of a Mips quirk. I see Reid Kleckner changed this object last year and found that it wasn't actually full so maybe we should move OutputArg::IsFixed into ArgFlagsTy now. I think SpeciallCallingConv ought to be eliminated and Mips16's calling convention be given it's own CallingConv def instead. If I remember rightly, I left it there because I didn't want to change Mips16 at the time. I'll comment on the OriginalArg* f...

...+ 44 4 llc 0x08de108a llvm::TargetData::getABITypeAlignment(llvm::Type const*) const + 44 5 llc 0x0863e289 llvm::TargetData::getTypeAllocSize(llvm::Type const*) const + 37 6 llc 0x08a707ed llvm::GetReturnInfo(llvm::Type const*, unsigned int, llvm::SmallVectorImpl<llvm::ISD::OutputArg>&, llvm::TargetLowering const&, llvm::SmallVectorImpl<unsigned long long>*) + 573 7 llc 0x089b59be llvm::FunctionLoweringInfo::set(llvm::Function const&, llvm::MachineFunction&) + 156 8 llc 0x08a4ec8a llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineF...

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

...part of ArgFlagsTy but I didn't want to add it there because it appeared to be full and I didn't want to make everyone have a 65-bit ArgFlagsTy just because of a Mips quirk. I see Reid Kleckner changed this object last year and found that it wasn't actually full so maybe we should move OutputArg::IsFixed into ArgFlagsTy now. AArch64, Hexagon, RISCV, and SystemZ all have the same requirement. AArch64 works around it by calling its CCAssignFnForCall helper for every argument (and passing IsFixed through to that). For GISel, it overrides assignArg so a different function can be called for va...

...gt; const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 172 8 llc 0x0000000100075353 llvm::TraxTargetLowering::LowerCall(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, bool&, llvm::SmallVectorImpl<llvm::ISD::OutputArg> const&, llvm::SmallVectorImpl<llvm::SDValue> const&, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 4179 9 llc 0x00000001004c3dcd llvm::TargetLowering::Lo...

...part of ArgFlagsTy but I didn't want to add it there because it appeared to be full and I didn't want to make everyone have a 65-bit ArgFlagsTy just because of a Mips quirk. I see Reid Kleckner changed this object last year and found that it wasn't actually full so maybe we should move OutputArg::IsFixed into ArgFlagsTy now. > > AArch64, Hexagon, RISCV, and SystemZ all have the same requirement. > AArch64 works around it by calling its CCAssignFnForCall helper for > every argument (and passing IsFixed through to that). For GISel, it > overrides assignArg so a different func...

...the isSplit flag in ArgFlagsTy but it only marks the first splitted argument piece, so it's not possible to know into how many pieces is the argument divided. So my question is how would i get this information or if it's possible to add for example the original size of the argument into the OutputArg/InputArg structs or the piece number if the argument is splitted. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110402/24d365ef/attachment.html>

...info when the Callee SDValue is a GlobalAddressSDNode doing cast<Function>(G->getGlobal()) (where G is GlobalAddressSDNode *G = dyn_cast<GlobalAddressSDNode>(Callee)), but this won't work when it is a ExternalSymbolSDNode, for that case i had to add additional info into the ISD::OutputArg struct to know the real size of the splitted argument. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120316/b55df694/attachment.html>

...SDValue ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI, SmallVectorImpl<SDValue> &InVals) const { SelectionDAG &DAG = CLI.DAG; DebugLoc &dl = CLI.DL; SmallVector<ISD::OutputArg, 32> &Outs = CLI.Outs; SmallVector<SDValue, 32> &OutVals = CLI.OutVals; SmallVector<ISD::InputArg, 32> &Ins = CLI.Ins; SDValue Chain = CLI.Chain; SDValue Callee = CLI.Callee; bool &isTailCall...

...; const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 166 9 llc 0x00000001000b72c6 llvm::MBlazeTargetLowering::LowerCall(llvm::SDValue, llvm::SDValue, llvm::CallingConv::ID, bool, bool&, llvm::SmallVectorImpl<llvm::ISD::OutputArg> const&, llvm::SmallVectorImpl<llvm::SDValue> const&, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + 3640 10 llc 0x00000001004fffe8 llvm::TargetLowering::Lo...

...lvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + > 172 > 8 llc 0x0000000100075353 > llvm::TraxTargetLowering::LowerCall(llvm::SDValue, llvm::SDValue, > llvm::CallingConv::ID, bool, bool&, > llvm::SmallVectorImpl<llvm::ISD::OutputArg> const&, > llvm::SmallVectorImpl<llvm::SDValue> const&, > llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::DebugLoc, > llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const + > 4179 > 9 llc 0x00000001...

Hello, Attached is a patch which significantly reworks how calls, incoming arguments, and outgoing return values are lowered. It's a major change, affecting all targets, so I'm looking for feedback on the approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, and to facilitate future refactoring and feature work.

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,