llvm dev - Jul 2013 - [LLVMdev] making a copy of a byval aggregate on the callee's frame

Hi - help!

I have read through previous threads on the subject of 'byval'  e.g.
   
https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI
   
https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM
   
https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg
and read through code (as best I can) but I am no wiser.

I am using the XCore target where the pointee data needs to be copied by the
callee (not the caller).
So:
        > I am not sure what this means though - when I generate code
        > from the LLVM assembly, do I need to do anything with byval?

        yes, the pointee needs to be passed by-copy, which usually means on the
        stack but could mean in a bunch of registers.

        > Either in the calling location or in the called function?

        The caller does the copy IIRC.  If you look at the .s file you should
see
        it happening.

unfortunately does not help me.


There seems to be some disagreement if it should be done in clang or llvm.
Indeed I have hacked clang's CodeGenFunction::EmitFunctionProlog() and it
works - but it is not nice.
BUT it seems most believe that it should be done within llvm using
'byVal'.

I have tried to follow the the 'byval' flag but am too ignorant to make
any meaningful headway viz:
I tried adding to the XCoreCallingConv.td:
    CCIfByVal<CCPassByVal<0,4>>        // pushes pointer to the
stack
and
    CCIfByVal<CCCustom<"XCoreCC_CustomByVal">>
But Have got stuck knowing if I can add the copy at this stage.
Is the pointee's details available or only the pointer's?
(Sorry if I have not dug deep enough to trace from pointer to pointee)

I also started to looked at the XCoreFrameLowering::emitPrologue()

Unfortunately, whilst stumbling around in the code is an interesting way to see
the scenery, I am losing any sense of direction I may have had to start with!

Any input gratefully recieved - including key source files or the order in which
things happen.
I'll try tracing through the calls (will -debug be enough) tomorrow.

thank you

robert


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130704/63d96a1a/attachment.html>

Hi Robert,
> I tried adding to the XCoreCallingConv.td:
>     CCIfByVal<CCPassByVal<0,4>>        // pushes pointer to the
stack
This looks sensible to me. After that it comes down to cooperation
between XCoreISelLowering's LowerFormalArguments and LowerCall
functions. LowerFormalArguments is at the beginning of a function and
is responsible for taking arguments out of registers and putting them
into sensible places for the rest of the function to use. LowerCall is
responsible for putting call arguments where callees will expect them
and making the call.

On most targets, for byval, LowerCall would store the argument by
value on the stack (likely with a memcpy equivalent from the actual
pointer that's being passed); and LowerFormalArguments would create a
fixed FrameIndex pointing there and record that as the address for use
by everything else.

You'll want to do basically the reverse: LowerCall will just put the
pointer it's given on the stack; LowerFormalArguments will do the
memcpy like operation into a local variable created for the purpose
(also a FrameIndex, but of a different kind), then it'll record that
frame-index as the address for everything else to use.

Hope this helps; come back if there's still stuff you don't understand.

Cheers.

Tim.

Hi Tim,

Thank you for the input.
I think I follow you.

I believe the LowerCall is doing what it needs to do - passing pointer either on
the stack or in register as per ABI.

The LowerFormalArguments() is where I am stuck.
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.
However, I don't want to push the pointer to the stack but COPY the pointee.
Indeed, I want to keep the pointer where it is BUT re-point it to a new object
copied onto the callee's stack.
Hmmm
What I really want it something like:

static bool CC_XCore(...) {
  if (ArgFlags.isByVal()) {  // a 'CCCustom' function
    Size = ValNo.pointee.size;                     // where do I get the
pointee's info from?
    NewVal = State.AllocateStack( Size, 4);  // how do I create space on the
callee stack?
    memcpy(NewVal, ValNo.pointee, Size);  // how do I copy from caller's
stack to callee's stack?
    ValNo.pointee=NewVal;                        // how re-point the pointer at
the callee's stack (rather than caller's data)?
  }

If this is the correct way to do it, I will continue to plough ahead.
As you can see, I have no idea what api functions I should be using :-)

Thank you
robert

________________________________________
From: Tim Northover [t.p.northover at gmail.com]
Sent: 04 July 2013 20:24
To: Robert Lytton
Cc: <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] making a copy of a byval aggregate on the callee's
frame

Hi Robert,
> I tried adding to the XCoreCallingConv.td:
>     CCIfByVal<CCPassByVal<0,4>>        // pushes pointer to the
stack
This looks sensible to me. After that it comes down to cooperation
between XCoreISelLowering's LowerFormalArguments and LowerCall
functions. LowerFormalArguments is at the beginning of a function and
is responsible for taking arguments out of registers and putting them
into sensible places for the rest of the function to use. LowerCall is
responsible for putting call arguments where callees will expect them
and making the call.

On most targets, for byval, LowerCall would store the argument by
value on the stack (likely with a memcpy equivalent from the actual
pointer that's being passed); and LowerFormalArguments would create a
fixed FrameIndex pointing there and record that as the address for use
by everything else.

You'll want to do basically the reverse: LowerCall will just put the
pointer it's given on the stack; LowerFormalArguments will do the
memcpy like operation into a local variable created for the purpose
(also a FrameIndex, but of a different kind), then it'll record that
frame-index as the address for everything else to use.

Hope this helps; come back if there's still stuff you don't understand.

Cheers.

Tim.