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

[Robert Lytton]

Hi Duncan,
Thank you, that is helpful.
I need the 2nd example for doing (1)
I now have a better understanding of the SelectionDAG and LowerFormalArguments() so will see how far I get.
(so much to know, so many ways to get lost)
Robert
________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Duncan Sands [baldrick at free.fr]
Sent: 05 July 2013 10:19
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] making a copy of a byval aggregate on the callee's frame

Hi Robert, suppose you have a "byval" argument with type T*, and the caller
passes a T* called %X for it, while in the callee the argument is called %Y.

The IR level semantics are:
   (1) a copy should be made of *%X.  Whether the callee or the caller makes the
copy depends on the platform ABI.
   (2) in the callee, %Y refers to the address of this copy.

There are many ways (1) can be codegened, it all depends on what the platform
ABI says.  Examples:
   - the caller allocates memory on the stack, copies *%X to it, then passes a
pointer to the stack memory to the callee as %Y.
   - the caller passes %X to the callee, the callee allocates memory on the
stack, copies *%X to it, then places the address of the copy in %Y
   - the caller loads *%X into a bunch of registers and passes the registers to
the callee.  The callee allocates memory on the stack, writes the contents of
the registers to it (thus reconstructing *%X), and places the address of the
memory in %Y.

Which method is used should be specified by the platform ABI.  For example,
what does GCC do?

Ciao, Duncan.

On 05/07/13 09:52, Robert Lytton wrote:
> Hi Tim,
>
> Thought about it last night and was coming to the same conclusion.
> 1. it cant be done at the end during lowering (target backend).
> 2. it should be part of llvm as the byVal needs to be handled.
>
> As a twist, I have been told that llvm-gcc can lower byVal into memcpy in the callee.
> I may take a look at this.
> I wonder if it ever emits 'byVal'...
>
> I still feel I don't understand enough about where byVal is used or what it means.
> Is it *only* used as an attribute of an argument pointer to argument data that is pending a copy?
> Once the memcpy is made, I assume the byVal is removed viz the arg pointer is replaced with a new arg pointer to the copied data.
> Thus, must *all* byVal attributes be replaced in the IR?
> I need to do more reading about other attributes and get more familiar with the IR in general...
>
> robert
>
> ________________________________________
> From: Tim Northover [t.p.northover at gmail.com]
> Sent: 05 July 2013 07:43
> 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,
>
>> This should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read.
>
> I've thought that once or twice when dealing with ABIs myself. That's
> certainly another possibility in your case. You could create a
> separate FunctionPass that gets executed early on and replaces all
> byval calls and functions with the correct memcpys.
>
> It wouldn't work for other targets because they need more control over
> just where the copy ends up, but it sounds like you shouldn't have an
> issue.
>
>> So, can it be done in the llvm?
>
> Yes, in multiple ways.
>
>> Should it be done in the llvm?
>
> I think so, one way or the other.
>
> Tim.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev