> Doesn't this mean you have to replicate all the machinations of > SelectionDAGBuilder to work out which argument you're dealing with at any > given moment, though?
We have some logic for matching flattened arguments back to original arguments. > How does this information get handled by the TableGen calling-conv code in > your situation? We only use CCCustom for our target. /Patrik Hägglund -----Original Message----- From: Tim Northover [mailto:[email protected]] Sent: den 4 april 2012 14:27 To: [email protected] Cc: Patrik Hägglund H; Bob Wilson; Anton Korobeynikov; James Molloy; cfe-commits Subject: Re: [LLVMdev] [cfe-commits] Fix handling of ARM homogenous aggregates On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html Thanks. I'd considered using MachineFunction fiddling purely from a LowerFormalArguments perspective (I hadnn't noticed the subtlety that LowerCall needs this info to be passed in). Doesn't this mean you have to replicate all the machinations of SelectionDAGBuilder to work out which argument you're dealing with at any given moment, though? I'm thinking of how it splits structs and implicitly adds sret parameters in particular, though there may be more I don't know of. How does this information get handled by the TableGen calling-conv code in your situation? The only way I can think of is a custom CCState which gets told about each argument as it passes by and allows CCCustom 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->isPointerTy()", CCAssignToReg<[P1, P2]>>; I've got a patch which implements it for ARM and X86 (though not HFAs using the features yet, I'm still musing on the best interface to present there -- "HFA* byval" for target simplicity or "HFA" for user simplicity), I'll see if I can clean it up for other targets and send it for comparison. The main issue with my approach is that split struct args are still tricky: they get identical types and another custom CCState is needed to handle them en-masse (to find out where we are in the struct). Optimal for that case might be an extra flag similar to isSplit(), but for structs. Thoughts? Tim. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
