[LLVMdev] [cfe-commits] Fix handling of ARM homogenous aggregates

[Tim Northover]

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.