[LLVMdev] making a copy of a byval aggregate on the callee's frame

[Tim Northover]

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 they see fit.

> static bool CC_XCore(...) {
>     <does weird and wonderful stuff>
> }

I think you're misinterpreting the purpose of these CC_* functions.
They don't actually do any of the work themselves. Their job is to
decide in broad terms where an argument goes and to record that
decision for the LowerWhatever functions. In fact, they don't have
access to any of the CodeGen or SelectionDAG machinery necessary to do
the job themselves.

The idea is that the DAG nodes we need to produce are actually
different in caller and callee, but whether some argument goes in R0
or R1 (or a stack slot) should hopefully be the same.

So the CC_* functions (& TableGen) take care of the first bit and then
the Lower* functions interpret those results in a target-specific way
(often). There are usually special checks for byval in those functions
which make copies at the appropriate points.

> As you can see, I have no idea what api functions I should be using :-)

I *think* you'll be fine with using CCPassByVal and won't need a
custom handler from what I've heard. At the very least you should be
focussing your attention on these Lower* functions for now. They're
horribly complicated, but I'm afraid that's something you just have to
deal with. They're where the real meaning of "byval" is decided.

Cheers.

Tim.