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

[Robert Lytton]

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