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

[Robert Lytton]

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.