llvm dev - Jul 2008 - [LLVMdev] Structs as first class values.

Chris Lattner wrote:
> On Jul 20, 2008, at 10:59 AM, Richard Pennington wrote:
> I'm sure the implementation will take the same approach, but it
won't
> necessarily be ABI compatible.  I don't know enough to say at this  
> point... it may end up being ABI compatible or not depending on  
> implementation details.
Hi Chris,

I was thinking about my problem and thought that there might be a good 
interim solution. I would like not to clutter my front end with stuff 
that will go away. How about a pass that runs before code generation 
that changes functions returning structs to void functions with the 
return pointer first parameter?

I've not written an LLVM pass (yet), and I'd I'd like to get my feet
wet. Does this seem like a reasonable (temporary) solution to this problem?

-Rich

Hi Rich,

> I was thinking about my problem and thought that there might be a good 
> interim solution. I would like not to clutter my front end with stuff 
> that will go away. How about a pass that runs before code generation 
> that changes functions returning structs to void functions with the 
> return pointer first parameter?
On this topic, you should look at the StructRetPromotion pass
(lib/Transforms/IPO/StructRetPromotion.cpp). This pass does exactly the
opposite of what you propose: It transforms return pointers in the first
parameter to first class returns.

This pass only operates on internal functions, though, so it does not have to
deal with ABI issues. If you want to support the C ABI (which requires a
pointer in the first argument to return any struct AFAIK), you might be better
off generating such code in your frontend. Any internal function can then be
simplified by the sretpromotion pass (perhaps it could be modified to take an
option for the maximum number of elements to put in the real return struct?)

Not sure how to go about this exactly, but perhaps this helps a bit.

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080721/249574f5/attachment.sig>

On Monday 21 July 2008 08:37, Matthijs Kooijman wrote:
> This pass only operates on internal functions, though, so it does not have
> to deal with ABI issues. If you want to support the C ABI (which requires a
> pointer in the first argument to return any struct AFAIK), you might be
> better off generating such code in your frontend. Any internal function can
> then be simplified by the sretpromotion pass (perhaps it could be modified
> to take an option for the maximum number of elements to put in the real
> return struct?)
This is not the same on all architectures.  For x86-64, for example, structs
are returned through the hidden first argument except if they are small
enough, in which case they are returned in registers.

I'm rather worried about Chris' statements regarding ABI compliance. 
This
is a very important issue for us and I would guess most commercial vendors.
We absolutely must be able to interoperate with third-party libraries.

Yes, we can implement the functionality ourselves but better that we have
one community-owned implementation than a bunch of private forks.

I'm hoping we can collectively discuss some of this at the dev meeting.

                                             -Dave

Matthijs Kooijman wrote:
> On this topic, you should look at the StructRetPromotion pass
> (lib/Transforms/IPO/StructRetPromotion.cpp). This pass does exactly the
> opposite of what you propose: It transforms return pointers in the first
> parameter to first class returns.
> 
> This pass only operates on internal functions, though, so it does not have
to
> deal with ABI issues. If you want to support the C ABI (which requires a
> pointer in the first argument to return any struct AFAIK), you might be
better
> off generating such code in your frontend. Any internal function can then
be
> simplified by the sretpromotion pass (perhaps it could be modified to take
an
> option for the maximum number of elements to put in the real return
struct?)
Hi Matthijs,

Thanks for the pointer. It was the first time I looked at an LLVM pass 
closely. Very nice and simple!

I think I will have my frontend pass the pointer. I can always back it 
out when return values are handled. Although it might be fun to try to 
implement a StructRetDemotion pass. ;-)

-Rich