[cfe-commits] [LLVMdev] Fix handling of ARM homogenous aggregates
Patrik Hägglund H
patrik.h.hagglund at ericsson.com
Thu Apr 5 03:01:09 PDT 2012
> 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.
From: Tim Northover [mailto:Tim.Northover at arm.com]
Sent: den 4 april 2012 14:27
To: llvmdev at cs.uiuc.edu
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).
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.
More information about the cfe-commits