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

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.

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
>

Hi Tim,

Correction to my last email.

What I should have said is that the new pointer is used by the callee rather
than the original byVal pointer arg.
(the byVal pointer arg remains but is not used by the callee).
viz:
define void @f1(%struct.tag* byval) {
entry:
  %st = alloca %struct.tag, align 4
  %1 = bitcast %struct.tag* %st to i8*
  %2 = bitcast %struct.tag* %0 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %1, i8* %2, i32 88, i32 4, i1 false)
  ; from now on %0 is not used
  ; callee uses the copy %st instead


Also, LowerFormalArguments() is not that late!
I just need to understand the process better :-/
 

As an aside, the Lang Ref states "The copy is considered to belong to the
caller not the callee".
I guess this has to do with permission rather than location in memory or in time
the copy happens.
Hence the copy can be made by the callee onto the callee's frame on behalf
of the caller!

robert

________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf
of Robert Lytton [robert at xmos.com]
Sent: 05 July 2013 08:52
To: Tim Northover
Cc: <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] making a copy of a byval aggregate on the callee's
frame

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

> What I should have said is that the new pointer is used by the callee
rather than the original byVal pointer arg.
Probably, I thought it looked a bit odd. Your code sequence looks
reasonable (apart from byval still being present in the argument list;
as you said before, lowering should probably remove that).
> Also, LowerFormalArguments() is not that late!
It's part of the LLVM IR to DAG conversion and target-specific. In
LLVM terms that is late. All of the opt passes have run by this point,
and they are the ones likely to make use of the extra freedom
provided.

Cheers.

Tim.

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